なぜ僕がテストを書くのか
どうも nasa です。 スリランカカレーを 2 日連続食べてお腹を壊しています。
辛いものもを食べてもお腹が痛くならない方法が知りたいです。教えて(ハート)
FrontEnd Test Night - Fukuoka #1に参加して来ました.
「私がテストに取り組み始めたきっかけ」というテーマの発表が多数あったので、僕もテストを書き始めたきっかけ、テストを書く理由などの考えをまとめようと思いこれを書いてます。
初めてのテスト
初めて書いたテストを頑張って思い出しました。 インターンのための課題アプリケーションで書いたのが初めてです。 User 登録する時にちゃんと validation が走るかを検証するテストを書いた思い出があります。 このときはテスト書くのめんどくせーと思ってましたが、業務に入ってからテストに対する考え方が変わります。
バグをリリースした!(わーい)
はい。初リリースでバクをリリースしました。(ちなみに昨日もやってしまった、、、マジで凹んでる)
自分の追加した機能によって、他のところが動かなくなりました、、、 で思ったんですが、他の機能のところにそれなりにテスト整備されていれば気づけるミスだったのかな〜と思い、テスト大事じゃ!と思いました。
月日は流れちょっと考えが変わる
変わるというか追加されるという感じですが。
テストは検証のためのもので、テストを書くことによって開発スピードは落ちると思っていました。 これは実装を終わらしてから、テストを書いていたからそう思っていたと思います。
で、あとに書くもんだからめんどくさいんですよね、、、 もう出来てるのに〜ダルダル〜と思いながら書いてました。 リリースもなれてきてバクもあまり出ないから初心を忘れていました。
で、最初に書くようにしてみました。TDD ってやつですね。 これやってから開発スピードが上がった気がします。 もちろん開発 + テストのトータル時間の話です。
で、なんで早くなったかな〜と考えました。
この 2 つが大きいかなと思いました
- 早く不具合に気づける
- 問題を分割できる
早く不具合に気づける
少し大きな実装がある時は幾つか機能、関数を作ってから最後に合わせる関しじゃないですか(人それぞれだが僕はそう)、で実装終わった後に動作確認〜というやり方だったのですがそれだと一つに不具合があった時に「どこだろ?」という不具合探しが始まります。
ある関数で期待してる出力が1だったのに 2 で出てる、それによって他が、、、みたいなケースですね。
ただ unit test を先に書いて関数書くと速攻で気づけるわけですよ。 (う〜ん、文章が下手なのと、自分の中でうまくまとまってないので伝わる気がしないが)
問題を分割できる
これは言わずもがなですが、、、(ちょっと書くの疲れてきた)
大きなタスクが来ます(ワオ!難しそう)で、それを小分けにしますよね(なんだ一個一個は簡単じゃねーか)その作業を頭の中でやってたのですが、unit test にすることでより明確になるんですね。
脳が小さいので頭の中でゴニョゴニョ考えるとよく分からなくなりますが、一旦テストコードに書くことで明確に何をしたら良いのか、この実装、設計で良いのかみたいなことに頭が回る用になる気がします。
[雑談] めっちゃ雑談なんだけど、オフィスで紙とペンを使いながらコード書いてるの僕だけなんだが、みんな脳がバカでかいのか?これが普通なの? 教えて
まとめ
テスト書こうぜ! 書いたことない人は一回 TDD でやってみて!マジで