■

テストコードを書いて意味があるのか懐疑的であった。

ネット上ではテストコードを書かないのは低レベルな開発者という風潮だ。

10年以上、テストコードを書く開発と書かない開発の両方を経験してきた。

■前提

・テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。

結論としては書かないほうがいいと思った。

・テストを書くためのコストが小さいなんて妄想もいいところだ。クソデカである。

　結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。

・100人以上かかわる巨大プロジェクトでも「テストコードを書かなかったので破綻した」、とかはなかった。

・テストコードを書くと実装の見落としが見つかってありがたいことはあった。

・デバッグするよりテスト書いたほうが早いことがあった。

・git pushするたびに毎回走っても全くの無意味だった。

・テスト対象が変わるとテストを書き直さないといけないのがサイアクだった。非効率化の極みだ。人生の無駄。

・その次にサイアクだったのは、テストコードの実行が失敗したときテストコードのバグであることが大半であったことだ。

・GUIソフトとテストコードは相性が悪いが、そもそも世の中のソフトウェア開発の大半はGUI開発である。

・テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。

　例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると

　メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。

・ふつ～に古典的なデバッグをすればいいと思う。

　テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。

Permalink | 記事への反応(1) | 09:50

ツイートシェア