「テスト駆動開発」を読みました.
会社であるプロジェクトに配属され, テストはカバレッジ100%のルール下で, テスト駆動開発を極力心がけるようにして1ヶ月半, その状態で読んだこの本は非常に面白いと感じました.
実のところ, 大学の頃一度この本を読もうと思ったことがあるのですが, そのときは開始30ページくらいでやめました. 当然テストなんてかけません. そこで, 大学の頃, なぜこの本を読み, テスト駆動開発を行うことができなかったかを当時コードを見ながら考えてみました.
当時のコード
人生の中で初めて, チームでサービスを1つ作り上げるという経験をしたプロジェクトです. 大学の授業でかならず1つ実験を取らなくてはいけないなかで, 一つだけ開発で単位をもらえるということでとったのが始まりです. サービス内容はREADMEにて
なお, 私のaws無料期間が切れたため, もうサービスは動いていません.
本を読んで心に残ったこと
- 小さなステップで確実に実装を進めていく
- まずは失敗をすることから
- グリーンな状態(常にテストが成功している状態を維持する)
- XUnitの精神はそのシンプルさ
… おそらく普段からテストを書いている人はそんなの当たり前だろと思うでしょう. 私自身もだんだんとこれが当たり前になりつつあります. しかし, 大学当時のコードを見ているとこれが以下に大切だということがわかりました.
できない理由1. 学生は 動くこと >>>>>>>>>>>>> 保守性
結論大学の授業は動くものがちゃんと出せれば評価されます. 出せればいいんです.
保守性? 小さなステップ? そんなこと知りません. その結果がこれです.
これはコントローラーです. コントローラーです
railsを使っているので, 当然MVCですが, これはCとVさえあれば動くようになっています.
本の第1章のように小さく, 小さく自分たちが実装することをリスト化し, 実装とリファクタリングのサイクルを踏む, なんてことをしなかった結果がこれです. 当然なにか問題が起こっても, すぐに原因はわからないですし, なにより他の人はだれもコードを読むことができません.
おそらく, このコードを見てもらえれば, 小さなサイクルで実装とリファクタリングをすすめることの大切さがわかると思います.
ちなみに, このコードは私が1人で書きました. なぜなら他の人が誰も手を付けられなくなってしまったからです.
できない理由その2. 悪魔の囁き「scaffold」
railsにはMVCの全てと, テストがすべて自動で作られる魔法のコマンド rails g scaffold というものがあります. さて, 成功するテストを学生がはじめから渡されるとどうなるでしょうか? 当然そのテストが落ちることと, エラーが起こることを嫌がります.
その結果がこちら
まあ, 書かなくなりますよね. もちろん自動生成されたテストは少し手を加えるとすぐに失敗するようになるので, 消します.
先程のコードと比べ, まだマシなように見えますが, 開発当時, マイナスの値を入れると予算がバグったり, アプリ内コインが無限に手に入るといったバグがあとからどんどん見つかると言ったことがありました.
失敗する理由3. テストはない上に, グリーンな状態は維持しない
これとかそうなんですが, 複数のDB操作が成功しないといけないのに, トランザクションを貼っていなかったため, しばらくデータの整合性が取れない状態や, jsのバグをほっといたのをまとめて直したコミットです. 仮にテストが合ったとしたらずっとレッドだったと思います. その結果, ブランチ名が add_something_something. 毎週の発表の際はここは来週直します, ここは来週直しますをずっと繰り返していたと思います.
失敗する理由4 シンプルさを大切にしない
このプロジェクトを踏まえて, 次はテストをちゃんと書こうと決めて作ろうとしたことがあったのですが, そこでRSpecを使ったのです. 理由は機能が良いとネットで見たから. 一人だけRSpecを使っていたことがあったやつがいたので, そいつは書けたのですが, ほかはまあ書けない. RSpec機能はいいのですが, 書き方に癖があるんです. minitestもまともに書けないくせに, minitestは機能が足りないとか言っていたので当時は馬鹿だったんでしょう. シンプルなことは大切です.
終わりに
結局の所, テストを書かない一番の理由は必要だと感じることがないことだと思っています. もし, 本当にテストが必要なのであれば, 上4つみたいなことは起こさないでしょうし. 読んだことない方は一度「テスト駆動開発」を読むことをおすすめします. 自分のしでかしたことがよく分かるので.
少しだけ昔の自分を褒めたいこと
テストは書いていませんでしたが, Circle CI + EC2 + Code Deployでデプロイの自動化ができていたことはよくやったなと思っています.(EC2触るの, これが初めてでした)
なお, これは2017年のCircle Ci 1.0を用いたデプロイなので現行の使用とは全く違うので参考にしないようお願いいたします...