複雑なドメインを扱うプロダクトの探索フェーズではいつどのようにテストをするのか / How to testing during exploratory phase

私たちのチームでは、複雑なドメインを扱うプロダクトの探索フェーズにおいて、ドメインモデルやユースケースを実装し、いくつかの方針を探索しては実装し直す。といったことを行ってきました。

仮に方針を決定しプロジェクトを前に進めたとしても、不確実性によって手戻りが発生することもしばしばあります。

元から捨てるかもしれない実装のテストをいつどのように書くべきでしょうか？テストの質や量によってどの程度不確実性に対処できるでしょうか？現実的に直面している日頃の悩みについてお話しします。

似たような悩みを抱える人の助けになれば幸いです。

Transcript

1. 複雑なドメインを扱うプロダクトの探索フェーズでは いつどのようにテストをするのか @boykush 2024-03-22 #NextbeatTechBar
2. 導入
3. About me @boykush SWE at Alp,Inc.
4. Our Products Domain Contexts Catalog Pricing Customer Contract Billing Analytics Invoice SaaS Accounting 継続課金ビジネス向けに販売管理・請求 業務の効率化を図る 複雑な料金計算モデルを持つ商品管理 継続課金としての契約 請求の自動スケジュール生成 請求書SaaSや分析クロスセル機能への連携 複雑なドメインを扱うプロダクト
5. 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に対するスタブ実装
6. 探索フェーズにおけるテスト
7. Domain UseCase Secondary Adapter Primary Adapter Domain UseCase Secondary Adapter Primary Adapter Domain UseCase Secondary Adapter Primary Adapter 探索フェーズを含むプロジェクト 複雑なドメインを扱う新規のコンテキストを実装 今後の機能拡張に耐えうるドメインモデルの探索 書籍「モノリスからマイクロサービスへ」のイメー ジが近い
8. 今日話すこと どのようなプロセスで探索フェーズのテストを進めてきたか 試行錯誤する上での現実的な悩みはなにか ※ここでいうテストは主にコード記述による（自動）テストを指す
9. 1. ドメインモデル仮実装 Domain UseCase Secondary Adapter Primary Adapter ドメインモデルによってモデルがどのような表現力 を得るかを探索する 設計書（ドキュメント）も書くが常に最新はコード に起こし仮実装している → テストは書かない 基本的にコードを捨てることが多いため
10. 2. ユースケース駆動実装 Domain UseCase Secondary Adapter Primary Adapter ユースケースが依存するコンポーネント群をI/Fのみ 定義 DBリポジトリI/F ドメインモデルの振る舞い仮実装 etc. ユースケースシナリオを記述するイメージでコード に起こす → 基本的にテストは書かない 未実装の振る舞いへのテストになるため 探索としてBDDのようなI/Fをどう利用するかのテ ストは不足（後述）
11. 3. 抽象とドメインロジッ クの実装 Domain UseCase Secondary Adapter Primary Adapter ユースケースが依存するコンポーネント群の具体実 装 コンポーネント群のI/F変更がある場合は2と3を行 き来する → 単体テストを書く 探索として期待する振る舞いが実現可能か、具体の 不確実性を下げる
12. 4. 外部通信層の実装と統 合テスト Domain UseCase Secondary Adapter Primary Adapter 他のCtxから呼ばれる外部通信層の実装 → 統合テストを書く I/Fと振る舞い双方のテスト I/Fの変動性が低いため、探索の繰り返しによる修正 を支えるテストになる
13. 現実的な課題・悩み
14. 探索中盤で手戻りが発生した場合テストを捨てるのか 責務の移動等によってI/Fが大きく変更すると利用できなくなるテストが発生する 今後の状況次第ではテストは再利用できる可能性 → テストケースのignoreによって課題を緩和 コメントアウトと違ってテストケースを一時的に無視しながらコンパイルは通し続ける "#calculatePrice" - { " 消費税10% で小計が計算される" ignore { ... } }
15. そもそも探索の手戻りを減らすためにはどうするか インサイト（要望）を拾い、ストーリーレベルで表現可能か否かを判断 → 場当たり的に行っており属人性が高い状況 → 不確実性を潰すため形式知による仕組み化 Agile Testingで紹介されている実例マッピング等の取り組みを強めたい
16. そもそもプロジェクト規模が大きくてテスト対象が広 すぎる？ 小さくなるよう努力はしている → アジャイルなチーム作りのブログ書いたよ “群れる” アジャイルチームのベストプラクティス
17. まとめ 1. インターフェースと振る舞いをレイヤ毎に区別して探索を進めた 2. 探索フェーズでいつどのようにテストを書くのかが確立できてきた 3. テストファーストを重要視して探索の手戻りを減らすのを頑張ろう