Pythonによるアーキテクチャパターン

第5章. ハイギアとローギアのTDD

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

サービス・レイヤーを導入することで、実用的なアプリケーションに必要なオーケストレーションの責務を追加することができる。 サービス・レイヤーは、ユースケースとそれぞれのワークフローを明確に定義するのに役立つ。リポジトリから何を取得する必要があるのか、どのような事前チェックと現状検証を行うべきなのか、そして最後に何を保存するのか。

しかし現状では、単体テストの多くはより低いレベルで動作し、モデルに直接作用している。 この章では、これらのテストをサービスレイヤレベルに移行する際のトレードオフと、より一般的なテストのガイドラインについて説明する。

ハリーは言う：テストピラミッドが実際に動いているのを目の当たりにして、光が射した瞬間だった

以下は、ハリーからの直接の言葉（ ）である：

当初はボブのすべてのアーキテクチャパターンに懐疑的だったが、実際のテストピラミッドを見て改心した。

ドメインモデリングとサービスレイヤーを実装すれば、単体テストが統合テストやエンドツーエンドテストを桁違いに上回る段階に到達できる。 E2Eテストのビルドに何時間もかかるような場所で働いていた経験からすると（要するに「明日まで待て」ということだ）、数分あるいは数秒ですべてのテストを実行することができるようになることが、どれほど大きな違いを生むかわからない。

どのような種類のテストを、どのレベルで書くべきかを決定するためのガイドラインについては、こちらをお読みいただきたい。ハイギア対ローギアの考え方は、私のテスト人生を大きく変えた。

テストピラミッドはどうなっているか？

サービスレイヤーを使用し、独自のサービスレイヤーテストを持つようになったことで、 のテストピラミッドにどのような影響があるか見てみよう：

テストの種類をカウントする

$ grep -c test_ test_*.py
tests/unit/test_allocate.py:4
tests/unit/test_batches.py:8
tests/unit/test_services.py:3

tests/integration/test_orm.py:6
tests/integration/test_repository.py:2

tests/e2e/test_api.py:2

悪くない！単体テストが15個、統合テストが8個、エンドツーエンドテストが2個だけだ。 これはすでに健全なテストピラミッドだ。

ドメイン層のテストはサービス層に移行すべきか？

これをさらに一歩進めるとどうなるか見てみよう。サービスレイヤーに対してソフトウェアをテストできるようになったので、ドメインモデルに対するテストは必要なくなった。その代わりに、第1章のドメインレベルのテストをすべてサービスレイヤーの観点で書き直すことができる：

サービスレイヤーでドメインテストを書き直す (tests/unit/test_services.py)

# domain-layer test:
def test_prefers_current_stock_batches_to_shipments():
    in_stock_batch = Batch("in-stock-batch", "RETRO-CLOCK", 100, eta=None)
    shipment_batch = Batch ...