社内の勉強会で発表しました。 今新規開発しているプロダクトでは、力を入れてHTTPテストを導入したので、それに関する発表でした。 プロダクトに関わる内容も多いのですが、できる範囲で公開します。
資料
Laravel Testing * https://laravel.com/docs/6.x/testing
Laravel Http Tests * https://laravel.com/docs/6.x/http-tests
PHPUnit * https://phpunit.readthedocs.io/ja/latest/
背景
=> テストコードによる改善
目的
- 凡ミスの抑制
- 想定漏れの可視化
- 一度テストコードを書けば、半永久的にデグレを防げる.
- MRレビューの時間短縮
- レビュー側がテストコードを書けば、再現条件の伝達が速く修正確認も容易
- テストコードを見れば仕様がわかる(実際の動作との差異がない)
- 安全にリファクタリングできる
- テストドリブンな開発で効率化
方針
HTTPリクエストの単位でテスト(GET・POSTなどのリクエストをして、レスポンスやDBのデータの変化を検証)
- 包括的に検証できるし、DBのモックなどを作らなくて良いので、UTより効率的
どうやったか
(プロダクトコードの紹介だったので、省略...。)
課題・問題点など
Seederの作成が一番難しい * 1つのSeederで様々なテストケースに対応できるようにするのは大変 * しかし複数のSeederを使い分けるとなると、テスト実行時間が急増する
CIに入れづらい * 時間がかかるので、Pushごとにテストを実行するのはまずそう... * masterにマージする場合だけ実行するとか
どれくらい詳細なテストを作成するか? * 正常系といくつかの異常系だけでも、成果は出る。 * 境界値テストとか、細かいとこを作り始めると、コストが大きくなりすぎる可能性も
フロントエンドのテスト * バックエンドに比べて成果を出すのが難しいので、現状は着手していない。
Q&A
QAチームにどこを担保してもらうか、負担が減るのか。
- フロントのテストは難しいが、バックエンドの担保はできるので良い
- 予想外の影響範囲のデグレに対し有効か。
- QAはブラックボックステスト。実装ロジックを把握しているエンジニア目線で、不具合の起きそうなところは重点的にテストコードを書くと効果的
- QAチームのテスト時点までに不具合を減らせるはずなので、リリース直前にバタバタしなくて済むはず
工数は増えましたか?
- 今くらいのざっくりとしたテストならほぼトントンで書ける(コピペで済む分が多く意外と時間がかからないのと、動作確認が省略できることなどでプラマイ0)
- もちろん、導入時には共通機能の実装や学習も含めて時間がかかる
- 諸々のメリットより、テストを書く方が工数はが少ない、という結果になるはず?
- 細かい条件のテストを増やしていくと、どこかの段階で逆転する可能性もあるかも
フロントとバックの仕様共有はどうしている?
- まだ試行錯誤中
- テストコードは仕様共有に使えるはず...(最初にテストコードを書く)
※ まだ導入したばかりなので予想・期待の部分も多く含みます。しばらく活用してみてから改めて長期的な結果を報告します。