複雑なドメインを扱うプロダクトの探索フェーズでは いつどのようにテストをするのか @boykush 2024-03-22 #NextbeatTechBar

導入

About me @boykush SWE at Alp,Inc.

Our Products Domain Contexts Catalog Pricing Customer Contract Billing Analytics Invoice SaaS Accounting 継続課金ビジネス向けに販売管理・請求 業務の効率化を図る 複雑な料金計算モデルを持つ商品管理 継続課金としての契約 請求の自動スケジュール生成 請求書SaaSや分析クロスセル機能への連携 複雑なドメインを扱うプロダクト

Archtecture Domain UseCase Secondary Adapter Primary Adapter Domain UseCase Secondary Adapter Primary Adapter Domain UseCase Secondary Adapter Primary Adapter MonolothAdapter クリーンアーキテクチャ Domain ドメイン層 UseCase ユースケース層 Secondary Adapter 内部通信層 Primary Adapter 外部通信層 モジュラモノリス ドメイン境界別にプロジェクトを分割 コンテキスト間はRPC I/Fに対するスタブ実装

探索フェーズにおけるテスト

Domain UseCase Secondary Adapter Primary Adapter Domain UseCase Secondary Adapter Primary Adapter Domain UseCase Secondary Adapter Primary Adapter 探索フェーズを含むプロジェクト 複雑なドメインを扱う新規のコンテキストを実装 今後の機能拡張に耐えうるドメインモデルの探索 書籍「モノリスからマイクロサービスへ」のイメー ジが近い

今日話すこと どのようなプロセスで探索フェーズのテストを進めてきたか 試行錯誤する上での現実的な悩みはなにか ※ここでいうテストは主にコード記述による（自動）テストを指す

1. ドメインモデル仮実装 Domain UseCase Secondary Adapter Primary Adapter ドメインモデルによってモデルがどのような表現力 を得るかを探索する 設計書（ドキュメント）も書くが常に最新はコード に起こし仮実装している → テストは書かない 基本的にコードを捨てることが多いため

2. ユースケース駆動実装 Domain UseCase Secondary Adapter Primary Adapter ユースケースが依存するコンポーネント群をI/Fのみ 定義 DBリポジトリI/F ドメインモデルの振る舞い仮実装 etc. ユースケースシナリオを記述するイメージでコード に起こす → 基本的にテストは書かない 未実装の振る舞いへのテストになるため 探索としてBDDのようなI/Fをどう利用するかのテ ストは不足（後述）

3. 抽象とドメインロジッ クの実装 Domain UseCase Secondary Adapter Primary Adapter ユースケースが依存するコンポーネント群の具体実 装 コンポーネント群のI/F変更がある場合は2と3を行 き来する → 単体テストを書く 探索として期待する振る舞いが実現可能か、具体の 不確実性を下げる

4. 外部通信層の実装と統 合テスト Domain UseCase Secondary Adapter Primary Adapter 他のCtxから呼ばれる外部通信層の実装 → 統合テストを書く I/Fと振る舞い双方のテスト I/Fの変動性が低いため、探索の繰り返しによる修正 を支えるテストになる

現実的な課題・悩み

探索中盤で手戻りが発生した場合テストを捨てるのか 責務の移動等によってI/Fが大きく変更すると利用できなくなるテストが発生する 今後の状況次第ではテストは再利用できる可能性 → テストケースのignoreによって課題を緩和 コメントアウトと違ってテストケースを一時的に無視しながらコンパイルは通し続ける "#calculatePrice" - { " 消費税10% で小計が計算される" ignore { ... } }

そもそも探索の手戻りを減らすためにはどうするか インサイト（要望）を拾い、ストーリーレベルで表現可能か否かを判断 → 場当たり的に行っており属人性が高い状況 → 不確実性を潰すため形式知による仕組み化 Agile Testingで紹介されている実例マッピング等の取り組みを強めたい

そもそもプロジェクト規模が大きくてテスト対象が広 すぎる？ 小さくなるよう努力はしている → アジャイルなチーム作りのブログ書いたよ “群れる” アジャイルチームのベストプラクティス

まとめ 1. インターフェースと振る舞いをレイヤ毎に区別して探索を進めた 2. 探索フェーズでいつどのようにテストを書くのかが確立できてきた 3. テストファーストを重要視して探索の手戻りを減らすのを頑張ろう