テスティングルールをチームにスムーズに導入する方法
こんにちは。
SO Technologies という会社でテックリードをしている島田です。
私は以前、電子国家として一部で有名なエストニアという国に住み、現地の Nortal という企業で働いていました。
当時私がいたチームでは、特に全体で決められたルールなどない状況で、メンバー各々の裁量でテストが書かれていました。
プロダクトのリリースを間近に控えた頃、開発メンバーも15人ほどになっていた中で、「そろそろ一定の品質を担保し続けるために、テストを書くにあたって何かしらルールを設けなければ」といった話が議題に挙がりました。
そこで、そのさらに前に勤めていた会社で同じような仕事をしたことのある私が、テスティングルールを決めてチームに導入することになりました。
今回の記事では、その過程で私がどのようなことをしていたのかを紹介します。
私が当時いたチームはメンバーが色んな国にバラけており、オンラインでのやりとりが主だったので、下記の通りドキュメントを充実させることにこだわる結果になりました。
コロナ禍の中、似たような状況になっているところも多いかと思いますので、必要でしたら是非参考になさってください🙂
テスティングルール導入3つのステップ
ステップ1: そもそもテストとは何かというのを明確にする
ルールの策定を始めた頃、チームには経験豊富なエンジニアだけでなく、半年前に業務を始めたばかりのインターン生を含めたジュニアメンバーが数名在籍していました。
彼らはただでさえ経験の浅いのに加え、チームの状況も上記は通りでしたので、書いたテストもあまり厳しくレビューされずにこれまで過ごしていました。
ですので、彼らに関しては、テストを書く上での勘所が養われていなかったり、そもそも単体、結合、E2E それぞれのテストはどのようなものなのか、業務を行う上で充分な理解が出来ていない可能性が高いというのが当時の状況でした。
そこで、当時開発していたプロダクトを開発する上で、最低限押さえておくべき各テストの定義をドキュメント化し、いつでも参照できるようにしておきました。
※そのドキュメントを作成する際に参考にした資料を、画面最下部に参考文献として載せておりますので興味がありましたらご覧ください
ステップ2: 各テストの具体的な書き方を参照出来るようにする
上記のステップでは各テストの定義をドキュメント化しましたが、それだけで実用レベルにかなうテストを書くというのは、ジュニアエンジニアには非常に難しいと言えるでしょう。
なので、単体、複合、E2E それぞれのテストを、まずは私が自分で書き、お手本として参照できるように残しておきました。
また、各お手本がどのように作られたのか、作る上でどのような観点に着目していたのかを、ステップバイステップで示すテキストもそれぞれ作成しました。
こちらは以前私が書いた "単体テストの書き方" という記事です。
記事内で示されているコードを実際に上記で書かれたものに置き換えた、これと同等の内容のものが各テキストになっている、とイメージしてくだされば内容が大体想像できるかと思います。
👇
ステップ3: 導入してからしばらくの間、テストの実装レビューを行う
準備したドキュメントが充分で無かった場合に備え、導入してから最初の1~2週間、テストを実装しているプルリクエスト全てをレビューしました。
幸いなことに、チームのメンバーたちは上記各ステップで用意したドキュメントの内容を理解した上で実装するよう努力してくれていたので、期間中は「このドキュメントのここを読んで実装しなおしてね」ぐらいしか特にコメントすることもありませんでした。
その後の話
上記実施した直後、私はコロナの影響で緊急帰国することになりまして、そのままエストニアの会社も泣く泣く辞めることになってしまいました。後日当時の同僚にその後の経過を聞いたのですが、どうやら上手く運用は続けられているみたいで安心しました😌
参考文献
Discussion