博士

ロボ子、自動テストって大事じゃけど、広範囲なテストは時間もかかるし不安定になりがちなんじゃな。

ロボ子

そうですね、博士。モックやスパイを使ったテストは高速ですが、リファクタリングが難しく、広範なテストの補完が必要になります。

博士

そこでじゃ！この記事では、広範なテスト、モック、インフラの無視、アーキテクチャの変更を必要としない第4の選択肢を提示しておるぞ！

ロボ子

それは興味深いですね。具体的にはどのような方法なのでしょうか？

博士

ふむ、この記事によると、[sociable](#sociable-tests)テストと[state-based](#state-based-tests)テストを、Nullableという新しいインフラ技術と組み合わせるらしいのじゃ。

ロボ子

Nullableですか？テストダブルのように見えるとありますが、実際には「オフ」スイッチ付きのプロダクションコードとのことですね。

博士

そうそう！Nullableはテスト時に機能をオフにできるプロダクションコードの一部ってことじゃな。まるで忍者のように、必要な時にだけ姿を現すのじゃ！

ロボ子

なるほど。それによって、広範なテストが不要になり、リファクタリングが容易になるのですね。

博士

そういうことじゃ！他にも、モックフレームワークより高速だったり、テスト設定が簡単だったり、レガシーコードとの互換性があったり…良いことづくめじゃ！

ロボ子

欠点もあるようですね。プロダクションコードの変更が必要だったり、手書きのスタブコードが必要だったり…。

博士

まあ、完璧なものはないからの。でも、A-Frame ArchitectureとかLogic Sandwichとか、色々なアーキテクチャパターンも紹介されてて、なかなか面白いぞ！

ロボ子

A-Frame Architectureは、インフラとロジックをアプリケーション層の下に配置し、インフラとロジックの間に依存関係がないようにするとのことですね。

博士

そうじゃ！そして、Logic Sandwichは、インフラ層を使ってデータを読み書きし、ロジック層を使って処理する！まるで美味しいサンドイッチみたいじゃな！

ロボ子

Traffic Copは、インフラ層とロジック層からのイベントをリッスンし、各イベントに対してLogic Sandwichを実装する、と。

博士

この記事には、他にもNarrow TestsやState-Based Testsなど、色々なテストパターンが載ってるから、ぜひ読んでみると良いぞ！

ロボ子

はい、博士。勉強になります。Nullableを使ったテスト、試してみる価値がありそうですね。

博士

そうじゃな！でも、Nullableを使いすぎると、コードがNullableだらけになって、まるで幽霊屋敷みたいになるかもしれんぞ！

ロボ子

…それは少し怖いですね。