私がRSpec書くときに気をつけていること【テストコード】

プログラミング

はーいRubyを書いてるみんな!RSpecは書いてるかな〜〜〜?

まだ書いたこともない君も、なんとなく空気を読んで書いてる君も、そもそもRSpecを知らない君も、私が普段どんなことを気をつけてテストコードを書いているか知っていただけると嬉しいです。

ちなみに私は学生時代から3年くらいRubyでチーム開発をしてきており、それを踏まえた上での所感を書いていきます。

ここでの話はRSpecの話ですが、APIでのテストコード全般についても同じことが言えるのかなって気がします。

この記事の目的

この記事の目的は「テストコード書くの無駄やん!!」って思っている人が「テストコード書いたほうがいいやん!!」って思えるようになることを目標に書きます。

なぜRSpecを書くのか

この命題はぐぐれば幾らでも出てきますが、現在の私のRSpec書く理由です。(実際には他にもあると思いますが)

実装での挙動が担保されていることを示せる
修正による他の箇所への影響の有無の確認

実装での挙動が担保されていることを示せる

テストコードでは様々なケースを用意して自分が実装したものが想定通り動いていることを示すことができます。

やっち
やっち

RSpecを書いてあれば、正常系で動作するものでも、パラメータの上限や下限や閾値での挙動がうまく動いているぜ!みたいなことも他の開発者がRSpecを見れば一発で分かります。

また、APIのパラメータやDBの状態に左右されるような機能を実装した場合には、想定通り以外の挙動も多々あります。

当然ですが、「想定外のデータの状態やリクエストが来たときにもこんな感じの挙動になる」ということが示せます。

やっち
やっち

こんな感じでテストケースを書いておくことで、共同開発者は、RSpecを見るだけで様々な状態での挙動がわかります

不安だったらこのテストケースも書けや!みたいなレビューもすることで、別の人が手元で動かさなくても挙動の担保が確認することが可能です。

修正による他の箇所への影響の有無の確認

長期的な共同開発をしているとよく「修正を加えたことによる他箇所での不具合の発生」みたいなことが発生して辛くなります。

やっち
やっち

拙者、自分が手を加えた箇所以外の箇所のコード読んだり手を加えたくない侍

そんなときに、RSpecで様々なケースが網羅されて書いてあると、他箇所での不具合に事前に気づくことができます。

また、どのケースで落ちたかを確認することでここに影響がでるやん!!!こっちも直さなきゃ!みたいな感じで不具合を消滅させることができます。

RSpecを書いてない状態でこういう不具合が発生すると、「どの変更でどの部分に問題が発生しているか」が分からず確認作業で地獄を見ます。つらい。

やっち
やっち

更にこれがstagingや本番に反映されると….って思うと身の毛がよだちますね。。。。

身の毛がよだたない人は身の毛がよだってください。

テストコードに対する考え方の変わり方

とはいえ、自分も開発初期から「テストコード書くぜぇぇぇぇぇ」みたいな感じではありませんでした。

これまでは様々な開発規模や期間を経た上でテストコードに対する想いが変わってきましたし、今後も経験を積む上で変わるかもしれません。

初期:「テストコードとか工数の無駄やんけ」

チーム開発初期の自分はRubyもRSpecも初心者であったため、RSpecを書く時間の方が実装している時間が長いみたいな状態でした。

テストコード書くか書かないかで工数が倍になるかならないかみたいな感じでした。

それでも上司から書いてと言われて「なんで?(涙目)」みたいな気持ちで書いていました。

やっち
やっち

この頃はチームもプロジェクトの規模も小さいものだったので動けばええやん!みたいな気持ちが結構強かったのもあります

2年目くらい:「書くと後々効いてくるやん」

様々なプロジェクトを転々として大きめな規模を経験したりするうちに、テストコードが大事なのでは????

書いたほうがこの挙動担保されるで!っていう証拠が示せるのがつよいなあと思うようになったし、機能追加系の変更の際に他の影響ないで!っていうのが示せるのが強いです。

やはりチーム規模が大きくなったり運用系の修正だとテストコード効いてくるやんって思うようになりました。

現在:「ちゃんと書いてお願い」

その後も色々な経験を積んでいくうちにテストコードは書いてくれ頼むから。。。。。という気持ちになるようになり、周囲に啓蒙するようにすらなりました。

チーム規模が大きく長期的な開発になるほどテストコードがないとほんとに地獄をみますよ(超絶スマイル)

やっち
やっち

社会人になってもやはりテストコードとはお付き合いしているのですが、ちゃんと書いてぷんぷんみたいな感じのうざい新卒になっています。

テストケースを書くときに意識していること

テストケースを書くときに意識していることはこんな感じです。

期待するレスポンスの検証

レスポンス形式の検証

変更されるデータの検証

パラメータはなるべく初期値を避ける(0とか1とか)

わざと失敗させる

失敗パターンの網羅

プライマリキーを指定してデータを生成しない

しきい値での検証

他にこんなことも意識するといいよ!とかあったら指摘していただけると参考にしたいと思います。

まとめ

やっち
やっち

長期的かつ多人数なプロジェクトはテストコードちゃんと書こうな!お兄さんとの約束だ!

コメント

タイトルとURLをコピーしました