テストについての個人の雑感
テストについての個人の雑感です。ここでいうテストってのは、なんかいわゆる開発をドライブするための開発者用のテストについてであって、品質の保証とかについては一切かんがえてません。
ざっくりいうと
「テストを書いた方が効率的に開発がすすむ場合にはテストを書く」
テストに対する認識
ソフトウェアにたいするテスト というものはソフトウェアそのものの価値には関係しない。
なので、テストにたいしてかけるコストなど、すくなければすくないほど良いにきまっておる。
Open Source Software のテストについて
オープンソースソフトウェアの場合、送られてきた patch の品質を travis ci で確認したい、っていう要件とか、手元の環境以外での動作確認などを行いたいので、それなりにテストを書く必要がある。
まして、僕が OSS として公開しているものはライブラリが多い。ライブラリは一般にテストをかきやすいし、動作確認の方法がテストを書くことしかないので、テストを書くのが自然である。
業務で記述するソフトウェアについて
基本、自社開発の web application を構築することを主な業務としています。
僕が記述しているソフトウェアの寿命について
Web Application の場合、だいたい3年ぐらいかなあ、と見積っている。
ただ一方、仕事で web application を記述している場合、実装ができあがったけどやっぱり企画がポシャってナシ!! ってなったりすることもあるし、なんともいえない。
どこまでテストを書くか
これに対する自分の指標は簡単で「テストを書いた方が効率的に開発がすすむ場合にはテストを書く」これだけです。
Web アプリケーションの場合、動作確認はエンジニアが手で動作確認するし、ディレクターさんが動作確認してからデプロイすることが多いかと思います。大きめのリリースの際には QA の人がチェックしてくれたりするので、品質はそのへんで保証するものという感じです。
自動テストコードは、開発をドライブするためのと捉えています。
カバレッジ率をどこまであげるか
基本的にカバレッジ率は気にしていません。ライブラリをかく時なんかは気にしてるんですけどね。
C0 カバレッジ100%とかも気にしてません。
ではどこのテストを書くか
テストコードを書くと時間がかかるので、なるべく書かなきゃかかないにこしたことはない、と思ってます。
なので、↑↑の大方針にしたがって、テストを書くところはなんとなく決めています。
Model のメソッド
モデルのメソッドのこまかい挙動の確認を browser からやるのはチョーメンドイので、スクリプトでサラサラっとかいたほうがいいですね。すぐかけるし。
Web API のエンドポイント
Web API のエンドポイントは、とてもテストをしやすいです。そして、手でテストするのはすごくむずかしいです。
ですから、テストケースを書いたことがすぐペイします。ちょっと書いて後々までお得なので、かいたほうがいいですね。
web API の end point はバグってるとエンドユーザーにすぐ影響でますし。
内部のこまかい挙動のテストは Model 側か Web API のどっちかにかけばいいと思います。両方にかいたら無駄じゃんね。
form とかのテスト
Selenium とかでのテストは、なんか受託案件だったり、超重要な部分だったり、そういう特別な事情がある場合にはかいてもいいけど、ちょっとした理由でテストケースがぶっこわれるし、マークアップエンジニアの変更でテストこわれたりして「辛い……」というかんじになるので、あんまやらないです。
サーバーサイドの実装、マークアップエンジニアがはいる段階ではすでにおわってることが多いですし。
CI について
CI なんて、なくてもみんながコミットのたびにテストスイートまわすならそれでいいんじゃないかと思います。
ただ、僕は「めんどくさくてしょうがない」という理由や「うっかりうごかすのわすれてしまう」という理由により、動かさないでコミットしてしまうことが多々あるんで、バックグラウンドでテストを実行してくれる CI が便利だな、とおもってます。
また、自分が一人で開発してる場合ならテストうごかすのたまにわすれるのとかはいいんですが、テストうごかない人と一緒に開発してると、どんどんテストケースがうごかなくなってイライラして発狂してしまうんで、他の人が git push したらすぐにテストして、うごかなくなってたらすぐ教えてくれる仕組みが必要不可欠だな、と感じておるわけです。
まとめ
「テストを書いた方が効率的に開発がすすむ場合にはテストを書く」