スマレジエンジニアyushiのブログ

スマレジエンジニアのブログ

社内の勉強会で発表しました(HTTPテスト)

社内の勉強会で発表しました。 今新規開発しているプロダクトでは、力を入れて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のレビューにかなり時間が取られる
  • システムを動かさないと仕様がわからない -> 属人化
  • リファクタリングが困難

=> テストコードによる改善

目的

  • 凡ミスの抑制
  • 想定漏れの可視化
  • 一度テストコードを書けば、半永久的にデグレを防げる.
  • MRレビューの時間短縮
  • レビュー側がテストコードを書けば、再現条件の伝達が速く修正確認も容易
  • テストコードを見れば仕様がわかる(実際の動作との差異がない)
  • 安全にリファクタリングできる
  • テストドリブンな開発で効率化

方針

HTTPリクエストの単位でテスト(GET・POSTなどのリクエストをして、レスポンスやDBのデータの変化を検証)

  • 包括的に検証できるし、DBのモックなどを作らなくて良いので、UTより効率的

どうやったか

(プロダクトコードの紹介だったので、省略...。)

課題・問題点など

Seederの作成が一番難しい * 1つのSeederで様々なテストケースに対応できるようにするのは大変 * しかし複数のSeederを使い分けるとなると、テスト実行時間が急増する

CIに入れづらい * 時間がかかるので、Pushごとにテストを実行するのはまずそう... * masterにマージする場合だけ実行するとか

どれくらい詳細なテストを作成するか? * 正常系といくつかの異常系だけでも、成果は出る。 * 境界値テストとか、細かいとこを作り始めると、コストが大きくなりすぎる可能性も

フロントエンドのテスト * バックエンドに比べて成果を出すのが難しいので、現状は着手していない。

Q&A

QAチームにどこを担保してもらうか、負担が減るのか。

  • フロントのテストは難しいが、バックエンドの担保はできるので良い
  • 予想外の影響範囲のデグレに対し有効か。
  • QAはブラックボックステスト。実装ロジックを把握しているエンジニア目線で、不具合の起きそうなところは重点的にテストコードを書くと効果的
  • QAチームのテスト時点までに不具合を減らせるはずなので、リリース直前にバタバタしなくて済むはず

工数は増えましたか?

  • 今くらいのざっくりとしたテストならほぼトントンで書ける(コピペで済む分が多く意外と時間がかからないのと、動作確認が省略できることなどでプラマイ0)
  • もちろん、導入時には共通機能の実装や学習も含めて時間がかかる
  • 諸々のメリットより、テストを書く方が工数はが少ない、という結果になるはず?
  • 細かい条件のテストを増やしていくと、どこかの段階で逆転する可能性もあるかも

フロントとバックの仕様共有はどうしている?

  • まだ試行錯誤中
  • テストコードは仕様共有に使えるはず...(最初にテストコードを書く)

※ まだ導入したばかりなので予想・期待の部分も多く含みます。しばらく活用してみてから改めて長期的な結果を報告します。