「やっぱTDD良いよね!」って言う話をしてたら「いや、お前アンチTDDって知ってる?」って突っ込まれました

友人と「やっぱTDD良いよね!」って言う話をしてたら「いや、お前アンチTDDって知ってる?」って突っ込まれました。

すみません知らなかったです…!!

確かに職業プログラマさんでテスト書ける人、書いてきた人って多くはないですよね。
外注でお願いした案件とかでも「お金は出すからテスト書いてくれません?」って言っても「いや、テストは書かないです」って拒否されることがあったりして、うーんどうしたものやら…、と。

そこで思ったのは、「テスト駆動」で開発しようとすると開発者がテストを書く必要があって、そうなるとテストの書き方についての知識が必要になるんだけど、そうじゃなくて「テストを書く人」を分けると良いのかな、と。
特にウェブ系だとBehatとかのE2Eテストとかは独自の言語(Mink、Cucumber、Gherkin+JS)とかになるから、開発者にテストの知識を付けるのって難しくて…、といった感じに。
あとはそもそもテストの目的としては、実務で発生する感じとしては「追加開発」とか「修正」とか、「フレームワークとかプラグインのバージョンアップ」とか、「DBデータのマイグレーション」とか「ミドルウェアの更新」とか、「ステージングと本番で動くか」とか、「外注したコードにバグが無いか」とか「メンバーにバグが無いか」といった点なので、ある時点の納品・検収といったときであれば責任はかなり明確で、その段階をグリーンという前提でテストを書いちゃう、っていうのはすごく理にかなっている気がしました。

あと「いや、テストは書かないです」っていうにもそういう理由があって、やっぱりテストとかリファクタリングってその恩恵を受けた経験、成功体験が無いと書こうって思えないのかなと。リファクタリングについては失敗体験は多いでしょうし、「えー、これ書き直すの?書き直しても検収始まってるし、バグ出たら面倒だし、成果物出ないし。」っていう感じになるのかなと。僕自身そうでしたし。

というわけでコード開発(プログラマ)と品質(テスト書く人)を分けていくと良いんじゃないかな、と思いました。

あとはCIですね。自動化周りもDockerが出てきてすごく便利なんですが、CIにはCIの知識とか経験が無いと難しいなぁと。
そのあたりも専門化できるといいな、と思いました。おしまい。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

%d人のブロガーが「いいね」をつけました。