『組織にテストを書く文化を根付かせる戦略と戦術 ＋α（再演／t_wadaさん講演部分の抜粋）』 #t_wada
-
- いいね！27
bopperjp
@bopperjp
ここにわこだわれ！ 再現性があって、繰り返し可能：いつでも同じ動作をする。 独立している：実行順序に依存しているのはダメ。 #t_wada
2016-03-11 20:32:28
V
@voluntas
#t_wada "リファクタリングしないとテスト書けないけれど、テスト書かないとリファクタリングできない” つまりデッドロックが発生している。どこかで無理する必要がある。
2016-03-11 20:34:28
bopperjp
@bopperjp
「レガシーコード改善ガイド」読め。 デッドロック: リファクタリングしないとテストがかけない<->テストがないとリファクタリングできない #t_wada
2016-03-11 20:34:30
V
@voluntas
#t_wada “仕様化テストのススメ” これは EtoE テストでやればなんとかなるパターンがあるよ。ウェブであれば HTTP レイヤーまで落とせばなんとかできる。
2016-03-11 20:36:09
しも𝕏
@smdhogehoge
構造上のデッドロックが起きているときはどっかで無理しなければいけない。つまり「手を入れてしまう。できるだけ安全に」 #t_wada
2016-03-11 20:36:30
超循環評価器
@hagino3000
すでに機能がある場合にどこからテストの実装の着手するか。リスクとテストコードによる効果、人の手による動作確認コストから求める。 大変な現場に放りこまれた時に使えそうな技だ #t_wada
2016-03-11 20:36:27
bopperjp
@bopperjp
メトリックスは変化を見る。分母分子を見ない。大きいコードのカバレッジは上がりづらいので、モジュール単位とかで見られるようにする。 #t_wada
2016-03-11 20:38:35
bopperjp
@bopperjp
静的解析を使いこなす 俯瞰の視点を得る。PDM, rubocop, Coverity.. テストを書き始めなくてもメトリクスが見える。 #t_wada
2016-03-11 20:40:36
bopperjp
@bopperjp
コードレビューのインフラに投資する。 Pull Request は効果的。誰かが見ると思うことが、質に寄与する。 #t_wada
2016-03-11 20:41:51
ツイトレンディー
@twtrendy
いま話題のワード：GENERATIONS / μ's4 / 赤味噌 / #t_wada / LINEアップデート / LINE 障害 / #クレヨンしんちゃん / 天皇陛下 / ライン / 新協力 / 優くん / 松井雅美
2016-03-11 20:42:02
bopperjp
@bopperjp
質が低い実装のテストを書いてはダメ。実装を変えるのを後押しするテストを書く。 どういうもの？実装からの距離が遠いやつ。 #t_wada
2016-03-11 20:43:58
bopperjp
@bopperjp
実装にベッタリなテストを書くと、構造を変えるとテストがfailするので、テストがfailするので実装を変えたくなくなる。カバー範囲に遊びをもたせる #t_wada
2016-03-11 20:45:11
しも𝕏
@smdhogehoge
実装が悪いこともある。その実装にピッタリ寄ったテストを書いてしまうと、改善した途端にテストが落ち始める。テストがカバーする範囲に遊びを持たせること。 #t_wada
2016-03-11 20:45:03
えすらはホルモン刺しが食べたい
@eslar
- テストを書くのは実装を変えるのが前提。 - クラス:テスト = 1:1だと、実装に寄り添いすぎて変える障壁となる。 - 実装変更の後押しになるテストを書く - カバー範囲に遊びを持たせる。実装からやや遠く #t_wada
2016-03-11 20:45:20