tawara's blog

雑記。個人の見解です。

テストをたくさん書いて体感したこと

仕事でテストをたくさん書いた。Railsのプロダクトなので、Rspecを使っている。一機能の主要部分をまるっと書いたら、得るものがあったので、メモとして残しておこう。

仕様に詳しくなれた

まずテストを書く上で、何が正しい状態なのかを知る必要があるので、とにかく仕様についての知識を集めた。ビジネス側のテキスト資料や動画資料が残っていたので、それでざっくり概要を把握できた。資料が残っていることはありがたい。またQAの方がテストした際に、テストのやり方の資料を残してくれていたので、それも参考にした。こうやって画面でデータを作ればいいのか、などを把握することができた。ただ開発に関してはローカル環境での開発方法の資料はあるものの、どんなクラスが登場人物で何をしているのかがあまり体系的にまとめられていなかった。そこで、コードを追いながら、どのようなタイミングでどのようなデータが作成されるのか、それらがいつ呼び出されてどのように機能しているのか、をデバッグしながら把握した。ビジネス側でやりたいことを、どのようにコードで表現しているのか、について詳しくなることができた。大変だった。

コードを追う力がついた、と思う

コードを眺めていても処理を把握できないので、デバッグしながら把握した。地道な作業だったけど、コードを追う体力のようなものがついた気がする。ひとつずつ、ちょっとずつ把握するしかない、という境地で時間をかけて理解した(ただそれでももちろん理解できていないところもある)。何を保存しているのか、についてより鋭く意識するようになった。至極当たり前のことのようだけれど、とにかくそう思った。すべてのコードが同じ重要度を持っていると思い込んでいた様に思える。結局、どのタイミングでどのようなデータを保存しているのか、をまず把握しなければならないのだと強く思った。

テストが書きやすいコードを書こうと思った

ひとつのメソッドでいろいろな処理をしている場合、単体テストを書くのに苦労した。メソッドをシンプルにすれば、その分テストがしやすくなるという気づきを得た。ただ単純にシンプルにすればいいのか、という点に関してはきっと議論がありそうなので、今後勉強するつもりだ。ただ、テストが書きやすいコードを書こう、と強く思えたことは単純に望ましい収穫だと思う。テスト好き。

テストの書き方について詳しくなれた

例えばあるメソッドのなかで、別のメソッドを呼んでいる場合、その別のメソッドが呼ばれているかどうかをテストする、という方法をはじめて知った。社内にはRspecについて詳しい人がいて気軽に相談するなかで教えてもらった。spyというもの*1。他には、letで変数を定義するときに、do - endで囲ってブロックを利用して記述できるなど。新しいことを知れてよかった。

テストがある安心感を得られた

今後、自分でテストを書いた箇所で、機能修正するチケットを割り当てられている。たくさん書いたコードで、そのチケットの不具合を検知することができた。うれしい!あとは不具合を修正してテストがグリーンになるように修正すればいい。そしてその修正による影響範囲は、すでにテストが書かれているので、安心してコード変更に取り組める。精神衛生上とても良い。目の前の修正に集中することができる。

テストに興味を持ちはじめた

テストを書くことの効用を感じることができた。とても感じた。なので、もっと開発フローにテストを効果的に取り組みたい。テストに関する知識も整理していきたい。何をテストすべきなのか、など。「品質」についても考えを深めることができそうだ。設計を検討したり、バックログリファインメントでの議論にも新たな観点から意見を出せるようになるかもしれない。というような心持ちでいたら、こういう記事に出会った。とても良かった。ので、記事内で言及されてる SoftwareDesign 2022/3 を買った。勉強するぞー。

bufferings.hatenablog.com

(了)