テストコード文化が失われていくまで
かつてはテストコードをがっつり書いていたそのチームから、テストコード書こうぜ！を推進していたメンバーが去っていった。
いつしか新規テストコードは書かれなくなり、
既存のテストもメンテナンスされなくなり、
テスト失敗も放置され、テストコードの価値は地に落ち、
完全にテストコード文化は失われていた。
（類似例）JenkinsおじさんがいなくなるといつしかCIが回らなくなる
品質担保は目視テストのみ！
なぜ、テストコード文化が失われていったのか
問題を整理してみると、原因と思しきものがいくつか見えてきた。- テストファーストだと要件定義に振り回されすぎ
=> 特に序盤は。
=> 安定して書けるのはユーティリティクラスくらい - コードカバレッジ目標
=> 実装相応の量のテストコードを書かなくてはならない
=> 時間的に書ける人と書けない人がでてくる
=> 書いたとしてもチームとしての取り組みになっていない - リリース後に時間とってドキュメントやテストコードを書こう
=> 結局時間を取らない・取れない・書かない
=> 書いたとしても日々の習慣としてではない
テストコード文化を取り戻した単純な１つのルール
それは、プルリクエストには、少なくとも１つ以上のテストコードが無くてはならない。
これだけだ。
実装に問題がない場合でも、テストコードが１件なければ、マージすることはできない。
逆に言うと、１つでもテストコードがありさえすればOKとした。
なぜ効果があったのか？
本ルールは、以下のような視点で設定した。- どうしたら最初の１歩を踏み出しやすいか？
- どうしたら負担なく継続できるか？
- どうしたら頻繁にテストコードを書く日常を作れるか？
また、最初から及第点を目指さず、以下のことはバッサリ切り捨てた。
- テストファーストでなくていい。
- 全ての実装にテストを書こうとしなくていい。
- コードカバレッジを追わなくていい。
今回の件では、ルールは緩いよ、でも強制よ、という「緩い強制」による習慣づけと意識改革が功を奏したように思う。
コードカバレッジガバガバやんけ！
テストを書くことが習慣化され、チームの文化として根付いてくると、いつしか、テストを書かないことに違和感を感じだすようになる。
最初はプルリクエストを通すためにテストコードを１件添えるだけだったのが、
次第に、実装量や影響範囲に比例したテストコードの件数になってきた。
依然としてルール上では、少なくとも１件のテストコードがあればOKなのにもかかわらずだ。
まとめ
個々人のレベルは高くても、チームとしてのレベルが１では良い仕事はできない。というかそれに根ざした問題ってけっこうありそうな気がする。。。
チームのレベルが上がってはじめて打てる手なんかもあるだろうし、
でもそのわりにチームとしてのレベル、機能してる具合、熟成度ってあんまり計測されてなかったりするし、それに対する評価にいたっては更になされてないように見える。
良いチームで働いてハッピーになろう。