リフカムでのテストへの向き合い方
こんにちは。リフカムでエンジニアをしている樫村 @kasssssy0000 です。
これまでのリフカムは、プロダクトの立ち上げに力を入れていて、テストの実装は、認証周りなど大事故に繋がる箇所を重点的に行い、他の箇所は、余裕があれば実装するという方針でした。
どこまでテストを書くのか判断も開発者に委ねられていて、人によって書くテストの粒度は異なっていました。最近では、どこまでテストを書くべきか迷うメンバーが多く出てきたので、チームでテストへの向き合い方をまとめて指針にすることにしました。
この記事では、決めた向き合い方をざっくりですが書いていこうと思います。
前提として
リフカムは、フルタイムで稼働できるメンバー７名と業務委託メンバー７名で３つのプロダクトを開発しています。２つのプロダクトでPMF(Product Market Fit)を目指して改善を続けている最中です。
人数的にやれることも限られていて、開発スピードを優先したい部分もあるため少し緩めの自分たちにあった丁度いいテスト方針にしました。
テストを書く目的
品質を担保するため
主に致命的なバグが発生していないか確認するためにテストを書くことにしました。分かりやすいものを挙げると以下のようなことを指してます。
・情報漏えい系のバグ（他社・他チームの情報が見えてしまうなど）
・利用者の意図しない処理が行われる系のバグ（メールの誤送信など）
・当たり前品質を満たしていない系のバグ（画面が表示されないなど）
致命的なバグと定義しているのは、テストをいつ書くべきか迷わないようにするためですね。
テストは、書こうと思えばどこまでも書けるので、最低ラインを定義してリリースを優先しないといけないケースでも迷わないようにしました。
変更に強いコードにするため
動作が担保されていると機能に手を加えやすいですよね。心理的にもハードルが低くなるので良いです。
リフカムでは、頻繁に機能をアップデートしたり、ライブラリのバージョンを上げる作業をしているので変更に強いコードにしておきたい気持ちがありました。
開発速度を上げるため
テストに動作確認を任せて、エンジニアは機能開発に集中できるようしたいです。
テストを書くことだけに着目すると工数増えてますが、テストは、動作確認時間やバグ調査時間の短縮が期待できるので、長期的に見ると開発速度が上がると考えてます。
基本的な向き合い方
カバレッジ100％は目指さない
カバレッジ100%は難しいですよね。
考えられる条件を全て洗い出すのは現実的に厳しいところがあります。
あまり、カバレッジに囚われて疲弊したくない想いがあったので、テストを書く目的がある程度達成できていればOKとしました。
バグを直したあとはテストを書く
バグが発生した箇所は、それほど複雑だったということでもあるので再度バグが発生する可能性が高いです。同じバグを繰り返すことは、利用者の信用を落としてしまう行為なので、バグを修正したら必ずテストを書いて品質を担保するようにしました。
テストで利用する値はユースケースがわかる値を使う
テストの値に「あああ」など意味を持たない値を使うと可読性が下がるので使わないようにしています。テストの可読性が下がると、単純にテストに手を加えづらくなるだけではなく、テスト自体にバグが発生しやすくなると思います。わかりやすいシンプルなテストを維持することは、正しく機能するテストを作成するために大事ですね。
Privateメソッドはテストを書かない
プライベートメソッドのテストは、パブリックメソッドのテストで振る舞いを担保できるので書かないことにしました。
自分たちが実装していないものはテストを書かない
自動生成したコードやライブラリの機能など、自分たちが実装していないものもテストを書かないことにしました。
さいごに
より詳細な方針も決めてはいるのですが、長くなってしまうので基本的な向き合い方だけを書かせていただきました。
まだまだ考えきれていない部分も多々ありますが、事業フェーズが変わるごとにテストへの向き合い方もアップデートしていければと思っています！
リフカムでは、正社員を含め業務形態・働き方を問わず、エンジニアを積極募集中です。興味がある方のご連絡をお待ちしてます 🙌