テストに導かれた成長するオブジェクト指向ソフトウェアのレビュー

この記事は、 Growing Object-Oriented Software、Guided by Tests （略してGOOS）のレビューです。 その中で、モックを使用せずに本からプロジェクト例を実装する方法を示します。

この記事の目的は、mokを使用するとコードがどのように害を受けるか、mokを削除すると同じコードがどれだけ簡単になるかを示すことです。 副次的な目標は、私にとって個人的に合理的であると思われる本と、それどころか、善よりも害を及ぼす本からアドバイスを選抜することです。 この本には両方ともかなりたくさんあります。

英語版： リンク

良い部品

良いものから始めましょう。 それらのほとんどは、本の最初の2つのセクションにあります。

著者は、自動テストの目標を、コードのリグレッションの検出に役立つ「セーフティネット」の作成と定義しています。 私の意見では、これはテストが私たちに与える最も重要な利点です。 セーフティネットは、コードが期待どおりに機能するという確信を得るのに役立ちます。これにより、新しい機能をすばやく追加し、既存の機能をリファクタリングできます。 コードの変更が故障につながらないと確信している場合、チームの生産性は大幅に向上します。

また、初期の段階で展開環境をセットアップすることの重要性についても説明しています。 これは、新しいプロジェクトの最優先事項である必要があります。 大量のコードを記述する前に、潜在的な統合エラーを初期段階で特定できます。

このために、著者は、アプリケーションの最も単純なバージョンであるウォーキングスケルトンの構築から始めることを提案します。これは同時に、その実装のアプリケーションのすべてのレイヤーに影響します。 たとえば、Webアプリケーションの場合、スケルトンは実際のデータベースから文字列を要求する単純なHTMLページを表示できます。 このスケルトンは、テストスイートの作成を開始するエンドツーエンドテストでカバーする必要があります。

この手法により、アプリケーションアーキテクチャに焦点を当てることなく、展開パイプラインの展開に集中することもできます。

この本は、2レベルのTDDサイクルを提供します。


つまり、各新機能をエンドツーエンドのテストで開始し、通常の赤緑リファクタリングループを介してこのテストを実行します。

ここでのエンドツーエンドは、進行状況の尺度のようなものです。 これらのテストの一部は、次のように「赤」状態である場合があります この機能はまだ実装されていません。これは正常です。 ユニットテストは同時にセーフティネットとして機能し、常に緑色である必要があります。

エンドツーエンドのテストができるだけ多くの外部システムに影響を与えることが重要です。これは統合エラーの特定に役立ちます。 同時に、著者は外部システムの一部をスタブに置き換える必要があることを認めています。 エンドツーエンドのテストに何を含めるかという問題は、プロジェクトごとに個別に決定する必要があります。普遍的な答えはありません。

この本は、エラーメッセージをより理解しやすくするために、4番目のステップを追加することにより、古典的な3ステップTDDサイクルを拡張することを提案しています。


これにより、テストがクラッシュした場合に、デバッガーを起動せずにエラーメッセージを見るのはそれほど簡単ではないことを確認できます。

著者は、最初から「垂直方向」にアプリケーションを開発することをお勧めします（エンドツーエンド）。 アーキテクチャの研磨に時間をかけすぎず、外部（UIなど）からのリクエストで開始し、最小限のコードでアプリケーションのすべてのレイヤー（UI、ロジック、データベース）を含むこのリクエストを完全に処理します。 つまり、事前にアーキテクチャを構築しないでください。

もう1つの素晴らしいヒントは、メソッドではなく動作をテストすることです。 多くの場合、これは同じものではありません。 動作の単位は、いくつかのメソッドまたはクラスにさえ影響を及ぼす可能性があります。

もう1つの興味深い点は、テスト対象システム（SUT）をコンテキスト非依存にすることの推奨事項です。

「どのオブジェクトも、それが実行されているシステムの概念を持つべきではありません。」

これは、本質的にドメインモデル分離の概念です。 ドメインクラスは外部システムに依存しないでください。 理想的には、現在の環境からそれらを完全に切り離し、余分な労力なしで実行できる必要があります。 コードのテスト容易性という明らかな利点に加えて、この方法はコードも単純化します。 ドメインに関係のない側面（データベース、ネットワークなど）に注意を払うことなく、サブジェクト領域に集中できます。

この本は、「あなたが所有するモックタイプのみ」というかなりよく知られているルールのソースです。 つまり、自分で書いたタイプにのみmokiを使用します。 そうしないと、mokiがこれらのタイプの動作を正しくモデル化することを保証できません。

興味深いことに、本の中で、著者自身がこのルールに数回違反し、外部ライブラリの型にmokiを使用しています。 これらの型は非常に単純なので、実際に独自のラッパーを作成してもあまり意味がありません。

不良部品

多くの貴重なヒントにもかかわらず、この本は潜在的に有害な推奨事項も示しており、そのような推奨事項はかなりあります。

著者は、ドメインモデル内の個々のオブジェクト間の通信に関しても、ユニットテストへのモックストアプローチの支持者です（ここでは、 モックストとクラシック主義の違いについて詳しく説明します）。 私の意見では、これは本の最大の欠点であり、残りはすべて本の結果です。

彼らのアプローチを実証するために、著者はアラン・ケイによって与えられたOOPの定義を提供します：

「主なアイデアはメッセージングです。 優れた拡張可能なアプリケーションを作成するための鍵は、さまざまなモジュールが相互に通信する方法を設計することであり、それらが内部的に配置される方法ではありません。

そして、オブジェクト間の相互作用は、単体テスト中に何よりも重視すべきものであると結論付けています。 このロジックによれば、クラス間の通信は、最終的にシステムを本来のものにするものです。

このビューには2つの問題があります。 まず、Alan Kayによって与えられたOOPの定義はここでは不適切です。 そのような広範囲にわたる結論をその根拠に基づいて描くことはかなり曖昧であり、現代のOOP言語とはほとんど共通点がありません。

ここに彼からのもう一つの有名な引用があります：

「「オブジェクト指向」というフレーズを思い付きましたが、C ++を意味するものではありませんでした。」

そしてもちろん、ここでC ++を安全にC＃またはJavaに置き換えることができます。

このアプローチの2番目の問題は、個々のクラスがきめ細かすぎて独立したコミュニケーターと見なされないことです。 それらが互いに通信する方法はしばしば変更され、最終結果とはほとんど関係がありません。最終結果はテストで検証する必要があります。 オブジェクト間の通信パターンは実装の詳細であり、通信がシステムの境界を越えたとき、つまりドメインモデルが外部サービスとの通信を開始したときにのみAPIの一部になります。 残念ながら、本はこれらの違いを生みません。

本で提案されているアプローチの欠点は、第3章のプロジェクトコードを見ると明らかになります。 オブジェクト間の通信に焦点を合わせると、実装の詳細に関与するためにテストが脆弱になるだけでなく、循環依存関係、ヘッダーインターフェイス、および抽象化の層が過剰になり、洗練された設計になります。

この記事の残りの部分では、本のプロジェクトをどのように変更できるか、そしてそれが単体テストにどのような影響を与えるかを示します。

元のコードベースはJavaで記述され、修​​正バージョンはC＃で記述されています。 ユニットテスト、エンドツーエンドテスト、UI、XMPPサーバーのエミュレータなど、プロジェクトを完全に書き直しました。

プロジェクト

コードに突入する前に、サブジェクト領域を見てみましょう。 この本のプロジェクトは、Auction Sniperです。 ユーザーに代わってオークションに参加するボット。 インターフェイスは次のとおりです。


アイテムID-現在販売されているアイテムの識別子。 ストップ価格-ユーザーとしてあなたがそれに対して支払う意思がある最高価格。 最終価格-あなたまたは他の入札者がこのアイテムに入札した最終価格。 最後の入札は、最後に行った価格です。 状態-オークションの状態。 上記のスクリーンショットでは、アプリケーションが両方のアイテムを獲得したことがわかります。これは、両方の価格が両方のケースで同じである理由です。

リストの各行は、サーバーからのメッセージをリッスンし、応答としてコマンドを送信することで応答する個別のエージェントを表します。 ビジネスルールは次の図に要約できます。


各エージェント（オークションスナイパーとも呼ばれます）は、画像の上部から参加状態になります。 その後、サーバーがオークションの現在の状態（最後の価格、入札者のユーザー名、最後の入札を中断するために必要な最低価格の上昇）を含むイベントを送信するまで待機します。 このタイプのイベントは価格と呼ばれます。

必要な入札がユーザーがアイテムに設定したストップ価格より低い場合、アプリケーションはその入札（入札）を送信し、入札状態に入ります。 新しい価格イベントで入札が先行していることが示された場合、スナイパーは何もせずに勝ち状態になります。 最後に、サーバーによって送出される2番目のイベントはCloseイベントです。 到着すると、アプリケーションはこのアイテムの現在のステータスを確認します。 勝っている場合は勝ちになり、他のすべてのステータスは失われます。

つまり、実際には、サーバーにコマンドを送信し、内部状態マシンをサポートするボットがあります。

この本で提案されているアプリケーションのアーキテクチャを見てみましょう。 これが彼女の図です（クリックして拡大）：



このような単純なタスクの測定を超えて複雑すぎると思う場合、それはそうです。 ここで、どのような問題が見られますか？

目を引く最初の観察結果は、多数のヘッダーインターフェイスです。 この用語は、このインターフェースを実装する単一のクラスを完全にコピーするインターフェースを指します。 たとえば、XMPPAuctionは、Auctionインターフェイスと1対1で対応し、AcutionSniperはAuctionEventListenerと対応しています。 単一の実装を備えたインターフェースは抽象化ではなく、 設計臭と見なされます。

以下は、インターフェースなしの同じ図です。 ダイアグラムの構造をより理解しやすくするために、それらを削除しました。


ここでの2番目の問題は、循環依存関係です。 これらの中で最も明白なのはXMPPAuctionとAuctionSniperの間ですが、それだけではありません。 たとえば、AuctionSniperはSnipersTableModelを参照し、接続はAuctionSniperに戻るまでSniperLauncherなどを順番に参照します。

このコードを読んで理解しようとすると、コードの循環的な依存関係が脳に負荷をかけます。 その理由は、このような依存関係では、どこから始めればよいかわからないからです。 クラスの1つの目的を理解するには、循環的に相互に接続されたクラスのグラフ全体を頭に入れる必要があります。

プロジェクトコードを完全に書き直した後でも、さまざまなクラスとインターフェイスが互いにどのように関連しているかを理解するために、かなり頻繁に図に目を向ける必要がありました。 私たち人間は階層をよく理解しており、循環グラフではしばしば困難を抱えています。 Scott Wlaschinは、このテーマに関する優れた記事を書いています。 周期的な依存関係は悪です。

3番目の問題は、ドメインモデルの分離の欠如です。 DDDから見たアーキテクチャは次のとおりです。


中間のクラスはドメインモデルを構成します。 同時に、オークションサーバー（左）とUI（右）と通信します。 たとえば、SniperLauncherはXMPPAuctionHouseと通信し、AuctionSniperはXMPPAcutionとSnipersTableModelと通信します。

もちろん、実際のクラスではなくインターフェイスを使用してこれを行いますが、ここでも、モデルにヘッダーインターフェイスを追加しても、依存関係反転の原則に従って自動的に開始されるわけではありません。

理想的には、ドメインモデルは自給自足である必要があり、その内部のクラスは外部のクラスと通信したり、特定の実装やインターフェイスを使用したりしてはなりません。 適切な分離とは、モブを使用せずに機能的なアプローチを使用してドメインモデルをテストできることを意味します。

これらすべての欠点は、開発者がパブリックAPIではなく、ドメインモデル内のクラス間の相互作用のテストに集中している状況の一般的な結果です。 このアプローチにより、ヘッダーインターフェイスが作成されます。 そうしないと、近隣のクラスを「殺す」ことができなくなり、多数の循環依存関係やドメインクラスが外部と直接通信できなくなります。

単体テスト自体を見てみましょう。 それらの1つの例を次に示します。

@Test public void reportsLostIfAuctionClosesWhenBidding() { allowingSniperBidding(); ignoringAuction(); context.checking(new Expectations() {{ atLeast(1).of(sniperListener).sniperStateChanged( new SniperSnapshot(ITEM_ID, 123, 168, LOST)); when(sniperState.is(“bidding”)); }}); sniper.currentPrice(123, 45, PriceSource.FromOtherBidder); sniper.auctionClosed(); } 

まず、このテストはクラス間の通信に焦点を当てているため、モックの作成に関連する大量のコードを作成および維持する必要がありますが、これはここでは最も重要なことではありません。 ここでの主な欠点は、このテストにテストオブジェクトの実装の詳細に関する情報が含まれていることです。 ここでのwhen文は、テストがシステムの内部状態を認識し、この状態をシミュレートしてテストすることを意味します。

別の例を次に示します。

 private final Mockery context = new Mockery(); private final SniperLauncher launcher = new SniperLauncher(auctionHouse, sniperCollector); private final States auctionState = context.states(“auction state”).startsAs(“not joined”); @Test public void addsNewSniperToCollectorAndThenJoinsAuction() { final Item item = new Item(“item 123”, 456); context.checking(new Expectations() {{ allowing(auctionHouse).auctionFor(item); will(returnValue(auction)); oneOf(auction).addAuctionEventListener(with(sniperForItem(item))); when(auctionState.is(“not joined”)); oneOf(sniperCollector).addSniper(with(sniperForItem(item))); when(auctionState.is(“not joined”)); one(auction).join(); then(auctionState.is(“joined”)); }}); launcher.joinAuction(item); } 

このコードは、システムの実装の詳細に関する知識の漏れの明確な例です。 この例のテストでは、本格的なステートマシンを実装して、テストされたクラスがこの特定の順序（最後の3行）で近隣のメソッドを呼び出すことを確認します。

 public class SniperLauncher implements UserRequestListener { public void joinAuction(Item item) { Auction auction = auctionHouse.auctionFor(item); AuctionSniper sniper = new AuctionSniper(item, auction); auction.addAuctionEventListener(sniper); // These collector.addSniper(sniper); // three auction.join(); // lines } } 

テスト対象システムの内部との接続性が高いため、このようなテストは非常に脆弱です。 このリファクタリングが何かを壊したかどうかに関係なく、些細でないリファクタリングはすべてその崩壊につながります。 これにより、価値が大幅に低下します。 テストはしばしば偽陽性をもたらし、このため、信頼できるセーフティネットの一部として認識されなくなります。

この本のプロジェクトの完全なソースコードは、次のリンクから入手できます。

mokを使用しない代替実装

上記のすべては非常に深刻な声明であり、明らかに、私はそれらを代替ソリューションでバックアップする必要があります。 この代替ソリューションの完全なソースコードは、 ここにあります 。

ドメインドメインを適切に分離し、循環的な依存関係や不要な抽象化を過度に行わずにプロジェクトを実装する方法を理解するために、アプリケーション関数を見てみましょう。 サーバーからイベントを受け取り、いくつかのコマンドでイベントに応答し、内部状態マシンをサポートします。


そして、それは本質的にすべてです。 実際には、これはほぼ理想的な関数型プログラミングアーキテクチャであり、そのような実装を妨げるものは何もありません。

代替ソリューションチャートの外観は次のとおりです。


いくつかの重要な違いを見てみましょう。 まず、ドメインモデルは外界から完全に分離されています。 その中のクラスは、ビューモデルまたはXMPPサーバーと直接対話せず、すべてのリンクはドメインクラスに向けられ 、その逆はありません。

サーバーであろうとUIであろうと、外界とのすべての通信はアプリケーションサービスレイヤーに与えられます。このレイヤーは、この場合AuctionSniperViewModelによって再生されます。 これは、外界の不要な影響からドメインモデルを保護するシールドとして機能します。着信イベントをフィルタリングし、発信コマンドを解釈します。

第二に、ドメインモデルには循環依存関係が含まれていません。 クラスの構造はツリーに似ています。つまり、潜在的な新しい開発者は、このコードを読み始めることができる明確な場所を持っています。 一度にツリー全体を頭に置く必要なく、ツリーを成形してツリーを段階的に上に移動することから始められます。 もちろん、この特定のプロジェクトのコードは非常に単純なので、循環依存関係があったとしても、問題なく読むことができます。 ただし、より複雑なシナリオでは、単純さと読みやすさの観点から、明確なツリー構造が大きなプラスになります。

ところで、よく知られているDDDパターン-Aggregate-は、この特定の問題を解決することを目的としています。 複数のエンティティを1つの集合体にグループ化することにより、ドメインモデル内のリンクの数を減らして、コードを簡素化します。

ここでの3番目の重要な点は、代替バージョンにはインターフェースが含まれていないことです。 これは、完全に分離されたドメインモデルを持つことの利点の1つです。実際の抽象化を表していない場合、インターフェイスをコードに挿入する必要はありません。 この例では、このような抽象化はありません。

新しい実装のクラスは、目的に応じて明確に分けられています。 これらは、ドメインモデル内のクラスであるビジネス知識を含むか、ドメインモデル外のクラスである外界と通信しますが、両方はありません。 この職務の分離により、一度に1つの問題に集中することができます。ドメインロジックについて考えるか、UIとオークションサーバーからのインセンティブへの対応方法を決定します。

繰り返しになりますが、これによりコードが簡素化されます。つまり、サポートが強化されます。 Application Servicesレイヤーの最も重要な部分は次のとおりです。

 _chat.MessageReceived += ChatMessageRecieved; private void ChatMessageRecieved(string message) { AuctionEvent ev = AuctionEvent.From(message); AuctionCommand command = _auctionSniper.Process(ev); if (command != AuctionCommand.None()) { _chat.SendMessage(command.ToString()); } } 

ここでは、オークションサーバーから文字列を取得し、イベントに変換し（検証はこの手順に含まれます）、スナイパーに渡し、結果のコマンドがNoneでない場合、サーバーに送り返します。 ご覧のとおり、ビジネスロジックがないため、アプリケーションサービスレイヤーは簡単になります。

モキなしのテスト

分離ドメインモデルのもう1つの利点は、機能的なアプローチを使用してテストできることです。 動作の各部分を互いに分離して検討し、この結果がどの程度正確に達成されたかに注意を払うことなく、生成される最終結果を確認できます。

たとえば、次のテストでは、オークションに参加したばかりのSniperがCloseイベントの受信にどのように反応するかを確認します。

 [Fact] public void Joining_sniper_loses_when_auction_closes() { var sniper = new AuctionSniper(“”, 200); AuctionCommand command = sniper.Process(AuctionEvent.Close()); command.ShouldEqual(AuctionCommand.None()); sniper.StateShouldBe(SniperState.Lost, 0, 0); } 

結果のコマンドが空であること、つまりスナイパーがアクションを実行していないこと、および状態がその後Lostになったことを確認します。

別の例を示します。

 [Fact] public void Sniper_bids_when_price_event_with_a_different_bidder_arrives() { var sniper = new AuctionSniper(“”, 200); AuctionCommand command = sniper.Process(AuctionEvent.Price(1, 2, “some bidder”)); command.ShouldEqual(AuctionCommand.Bid(3)); sniper.StateShouldBe(SniperState.Bidding, 1, 3); } 

このテストでは、現在の価格と最小増分が設定された価格制限よりも小さい場合に、狙撃兵がリクエストを送信することを確認します。

mokaが正当化される可能性がある唯一の場所は、外部システムと通信するApplication Servicesレイヤーをテストするときです。 しかし、この部分はエンドツーエンドのテストでカバーされているため、この特定のケースではこれは必要ありません。 ちなみに、この本のエンドツーエンドのテストは素晴らしく、変更や改善が可能なものは見つかりませんでした。

代替実装のソースコードは、 ここにあります 。

おわりに

個々のクラス間の通信に焦点を合わせると、テストが脆弱になり、プロジェクトアーキテクチャ自体が破損します。

これらの欠点を回避するには：

• ドメインクラスのヘッダーインターフェイスを作成しないでください。
  
• コード内の循環依存関係の数を最小限にします。
  
• ドメインモデルを分離します。ドメインクラスが外部と通信しないようにします。
  
• 不要な抽象化を減らします。
  
• ドメインモデルをテストするときは、クラス間の通信ではなく、状態と最終結果の確認に焦点を合わせます。
  

Pluralsightコース

実用的な単体テストに関する新しいPluralsightコースを受講しました。 その中で、ユニットテストの構築の実践について話そうとしました。これにより、最小限の労力で最高の結果が得られました。 上記の記事のガイドラインがこのコースの一部になり、多くの例とともに詳細に検討されています。

また、30日間（私のコースだけでなく、ライブラリ全体に）Pluralsightに無制限にアクセスできる多数のトライアルコードがあります。 誰かが必要な場合-個人的に書いて、私は喜んでそれを共有します。

コースリファレンス： 実用的な単体テストスイートの構築 。