#blog [https://martinfowler.com/articles/practical-test-pyramid.html](https://martinfowler.com/articles/practical-test-pyramid.html) # なぜこのブログを読んだか テストピラミッドの具体的な例が紹介されていてよかった [[Merpay Tech Fest2021 Day5 QA, Testing and DevOps]] の発表の中でもふれられてた # 何が書かれているか テストピラミッドという概念はイメージもしやすいし、広く知られているが実際にチームで運用していくのは難しい。 テストピラミッドの概念をもう少し具体的に書いている # メモ ## Unit Test  > The foundation of your test suite will be made up of unit tests. Your unit tests make sure that a certain unit (your subject under test) of your codebase works as intended. Unit Test はあるコードに着目して、Stub や Mock を使ってそのクラスの振る舞いをテストする。 ## Integration Tests   > All non-trivial applications will integrate with some other parts (databases, filesystems, network calls to other applications). When writing unit tests these are usually the parts you leave out in order to come up with better isolation and faster tests. Still, your application will interact with other parts and this needs to be tested. アプリケーションは実際何かしらの外部環境に依存している。 Unit Test はこのあたりの外部依存を Stub や Mock で実装していたのでこの外部環境との接続したテストを行う。 後述の Contract Test を考慮するとここでは、自分たちのチームでコントロール可能な範囲での外部環境依存のテストを行うことを Integration Test と呼ぶという認識をした ## Contract Test  現代のソフトウェアは、複数チームでそれぞれ各々のサービスを実装してAPIとして他のサービスに提供していることが多い。 このプラクティス自体は、[[Team Topologies]] や [[Monoliths vs Microservices is Missing the Point—Start with Team Cognitive Load - Team Topologies]] や [[Modular Monoliths • Simon Brown • GOTO 2018]] でも言われている通り、独立した小数で開発を継続していけるのでよい組織的プラクティスと言える。 一般的には、このサービス間は Consumer と Provider に立場がわかれ (開発している機能によってもその従属関係は変わる)、それぞれの間には何かしらの I/F 定義 (つまり Contract) があるはず。 ここでは、Contract が想定通りであるかということを実際のサービスに問い合わせることで確認するというテスト。 基本的には実装をしている側である Consumer が主体者となってテストするのがよく Consumer Driven Test として紹介されている。 ## UI Test > UI tests test that the user interface of your application works correctly. User input should trigger the right actions, data should be presented to the user, the UI state should change as expected. > UI Tests and end-to-end tests are sometimes (as in Mike Cohn's case) said to be the same thing. For me this conflates two things that are rather orthogonal concepts. > Yes, testing your application end-to-end often means driving your tests through the user interface. The inverse, however, is not true. > Testing your user interface doesn't have to be done in an end-to-end fashion. UI Test は End-to-End Test の 手法でテストされることが多いが、必ずしもそういった方法が使われる必要はない。 例えば、UI Test フレームワークを使ってある画面だけを起動してテストするようなことも可能である。 ## End-to-End Test  - End-to-End Test は、実行が遅いし保守性が低いので最低限に留めるべきである。 - その際には、アプリケーションにとって重要なアクションのみを対象にするなどで優先度を考慮する - もしもプロダクトにQAチームがあれば、QAチームがこれらのメンテナンスをするのもプラクティスとしては良い - [[Merpay Tech Fest2021 Day5 QA, Testing and DevOps]] や [[QA Tech Talk - リリースを早めるQA]] でも紹介されている # 感想 - Integration Test の境界線を引くのが難しい問題が一般にあると思うが、 Contract Test というのを入れたのは新鮮で画期的だった