友人と「やっぱTDD良いよね！」って言う話をしてたら「いや、お前アンチTDDって知ってる？」って突っ込まれました。
すみません知らなかったです…！!
確かに職業プログラマさんでテスト書ける人、書いてきた人って多くはないですよね。
外注でお願いした案件とかでも「お金は出すからテスト書いてくれません？」って言っても「いや、テストは書かないです」って拒否されることがあったりして、うーんどうしたものやら…、と。
そこで思ったのは、「テスト駆動」で開発しようとすると開発者がテストを書く必要があって、そうなるとテストの書き方についての知識が必要になるんだけど、そうじゃなくて「テストを書く人」を分けると良いのかな、と。
特にウェブ系だとBehatとかのE2Eテストとかは独自の言語（Mink、Cucumber、Gherkin＋JS）とかになるから、開発者にテストの知識を付けるのって難しくて…、といった感じに。
あとはそもそもテストの目的としては、実務で発生する感じとしては「追加開発」とか「修正」とか、「フレームワークとかプラグインのバージョンアップ」とか、「DBデータのマイグレーション」とか「ミドルウェアの更新」とか、「ステージングと本番で動くか」とか、「外注したコードにバグが無いか」とか「メンバーにバグが無いか」といった点なので、ある時点の納品・検収といったときであれば責任はかなり明確で、その段階をグリーンという前提でテストを書いちゃう、っていうのはすごく理にかなっている気がしました。
あと「いや、テストは書かないです」っていうにもそういう理由があって、やっぱりテストとかリファクタリングってその恩恵を受けた経験、成功体験が無いと書こうって思えないのかなと。リファクタリングについては失敗体験は多いでしょうし、「えー、これ書き直すの？書き直しても検収始まってるし、バグ出たら面倒だし、成果物出ないし。」っていう感じになるのかなと。僕自身そうでしたし。
というわけでコード開発（プログラマ）と品質（テスト書く人）を分けていくと良いんじゃないかな、と思いました。
あとはCIですね。自動化周りもDockerが出てきてすごく便利なんですが、CIにはCIの知識とか経験が無いと難しいなぁと。
そのあたりも専門化できるといいな、と思いました。おしまい。