プロセスに従ってテストを進め、ユースケースの内部の実装をやり切るだけとなります。TDDに慣れている開発者からすればお馴染みの感覚かもしれませんが、テストケースとの対話を通じて、ぼやけたイメージしかないユースケースの詳細仕様を固め、また実装していきます。事例まずは、テストで実際にユースケースを動かすにあたり必要となる、DI機構の整備を行います。DI/IoCコンテナは生成関数を定義すると、テスト等での取り回しがしやすくなります。registry;};また、自動テスト機構の整備を行います。クリーンで好きな選択肢ですが、オニオンアーキテクチャのテストは基本的に複雑にはならないので、シンプルな機能で足りるという意味でもAVAにしています。モックを作成していきます。インターフェースの契約を満たすもっとも単純な形にしますが、もしテストのためにSpyのような機能が必要であれば加えます。いった機能が必要にも関わらず、テストで使えるモックが作れないのであれば、インターフェースを見直したほうがよいでしょう。いうロジックだけが残りました。中をデータが流れては行きますが、テストが検証するのは結果的に、何ら副作用を持たないメッセージ構築のルールのみとなりました。ユースケーステストで検証されるのは普通、アーキテクチャに依存しない部分のうち、実務上もっとも面倒で、もっともソフトウェアの挙動にとって重要なものになります。呼ばれるものですが、外部依存関係を全て排除し、大部分の知識を契約のインターフェースに委ねた後に見えてくるのは、案外このように単純な宣言的定義だけだったりするかも知れません。使ってユースケースを実装します。ユースケースに必要な役割を全てInversifyJSの機構によって注入し、これらを用いて仕様を表現します。最終的には、おおよそ以下のような形になりました。);ここまでで、外部依存関係を含まず、どんな環境でも実行できるテストが用意できました。これは、ビルド時間を除けばわずか数秒で、ビジネスロジックの包括的な検証を行えるものです。次のStepではこれを、アプリケーションとして動かしていきます。インターフェースによる契約関係によって保証されています。契約を守って動作するかどうかは、実際のインフラストラクチャと接続された状態で検証しなければ意味がありません。外部サービスやDBをテストしようとするなかれ、とはTDDの金言ですが、オニオンアーキテクチャではこの警告に対して、具体的な指針を提供します。ユースケースとの契約はユースケースの発展に伴って変更される場合があることを、心に留めておく必要があります。