実際のコードのテストへのアプローチ。 パート2

ほとんどの人がこの意見に出くわしたと思います。テストを書くのは難しいです。テストを書く例はすべて、最も単純なケースのために与えられていますが、実際には機能しません。 しかし、最近では、テストの作成は非常に簡単で、些細なことでもあるという印象を受けました。 最初の部分で始めたことを続けます。

リクエストのテストを続けます

私はあなたのことを知りませんが、複雑なデータベースクエリを書くために、SQLクエリまたはHQLクエリが常に不安を引き起こしているかどうかは関係ありません。 場合によっては、非常に有能なリクエストを作成し、必要なことを絶対に実行し、本番環境でコードを実行すると、すべてがうまくいくように見えますが、しばらくすると、何かが完全に計算されるようなデータの組み合わせがあることがわかります間違っている、または一部のレコードが欠落している、またはそのような何か。 これは、多くの外部結合を使用する必要があるクエリや、一部のフィールドでデータをグループ化する必要があるクエリの場合に特に当てはまります。 一般的に、もちろん、私は願っています。 複雑なクエリ。 私たちのプロジェクトでは、Flexプログラマの生活を促進するために、複雑な分岐データを単純なテーブルの形式で提供するようなものがいくつかありました。 このすべての複雑さに対する私たちの答えは？ もちろんテストです！ 同時に、私は生きた人間でもあり、このタイプの繰り返し（またはわずかに異なる）コードの束で20のテストを書くことはまったく面白くないです。

public void test() { Application app1 = ApplicationMother.makeApplication(); Version version11 = VersionMother.makeVersion(app1); save(app1, version11); DeploymentMother.makeDeployment(app1); DeploymentMother.makeDeployment(app1); //   4  List<ResultRow> result = myRepository.executeComplicatedQuery(); assertEquals(app1.getId(), result.get(0).getAppId()); assertEquals(version11.getId(), result.get(0).getVersionId()); assertEquals(2, result.get(0).getDeploymentCount()); //      } //   19       
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この苦痛を避けるために、テストを書くこともプログラミングであり、製品自体を書くことほど面白くないことを思い出します。 そして、2番目に適用するすべてのアプローチは、最初のアプローチにもまったく適用できます。 特に、リファクタリングは私たちの友人であることを思い出してください。 リモートでも繰り返しコードのように見えるものはすべて、ヘルパーメソッドとヘルパークラスで容赦なく削除されます。

 public void testDeletedDeploymentsDontCount() { TestData data = app("app 1") .withNonDeletedVersion().deployedTimes(2) .withDeletedVersions(1).deployedTimes(2) .app("app 2") .withNonDeletedVersion().deployedTimes(1); queryAndAssert( data.makeExpectedRow(1, 1, 2), data.makeExpectedRow(1, 2, 0), data.makeExpectedRow(2, 1, 0) ); //  TestData.makeExpectedRow  : //    ,    ,    deployment-.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すでに良いですよね？ コードは比類のないほど読みやすくなりました。 メソッドチェーンを使用する場合（私の意見では、これはExpressionBuilderパターンと呼ばれます）、常にメソッドを追加する機会があり、その呼び出しによって構造全体が作成されます。次に例を示します。

 TestData data = times(5).deployedAppAndVersion() .times(2).deletedDeployedApp();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい、このために一定量のユーティリティコードを記述する必要がありましたが、第一に、それは本当に面白く、第二に美しいものでした。 つまり、私はそれを楽しんで、新しいトリックを学び、恩恵を受けました。なぜなら、今ではいつでもソースデータの愚かな組み合わせのテストをいくつでも追加でき、力から2分かかりますからです。 興味がある場合、時間のおおよその内訳：

• リクエストの最初のバリアントの作成：20分。
• 最初の2つのテストの作成：10分。
• thirdい、不快な3番目のテストを書く：10分。
• リファクタリング番号1：30分。
• テスト4〜8の記述、リファクタリング2：10​​分。
• figが機能しなかったため、リクエストを書き直し、判明し、すべてのテストが正常に起動しました：20分。
• テストの追加、テストの簡単なリファクタリング、リクエストの修正：10分間で4回。

すべてのエラーのバグレポートがあった場合、どれくらい時間がかかりますか、リクエストを再度開き、どのフリークがそれをプログラムしたのかを思い出し、なぜそれを修復し、コードを送信したかなど、想像するのも怖いです。このアプローチは、クエリテストだけでなく適用できます。 したがって、次に進みます。

サードパーティサービスとの相互作用のテスト

私たちの場合、仮想化インフラストラクチャはサードパーティのサービスとして機能します。 仮想マシンを開始、消滅、監視するサービス。 ここでの困難は海です。 彼女が自分の中で何をしているのか誰も実際には知らないという事実から始まり（「彼女は小さなネオンを持っています」、ハァッ）、彼女のAPIは前世紀の1か所で完全に作られたという事実で終わります。彼女に（インフラストラクチャ）を伝えるために：「このような3つの仮想マシンを起動し、完了したらここでノックします」、作成するコマンドを実行し、その後常にステータスを要求するなど。 同時に、各プログラマーは自分のマシンですべてのテストを非常に頻繁に実行し、チームは地理的に分散しているため、常に実際のインフラストラクチャを操作するのは非現実的です。ここでは、すべてのテストをいくつかのグループに分けます。 通常、ユニット、統合、受け入れテストは区別されます。 しかし、私にとっては、テストの統合グループは少しわかりにくいです。 前のセクションで説明したクエリテストは単体ですか、それとも統合ですか？ したがって、グループ番号1にはラップトップで実行できるすべてのテストが含まれ、グループ2には企業ネットワーク内で実行する必要があり、外部依存関係（仮想化インフラストラクチャなど）があるすべてのテストが含まれます。 グループ番号3もありますが、それについては後で質問します-実際に何をテストする必要がありますか？ ライブラリやサードパーティのサービス自体はテストしていませんので、インフラストラクチャが私たちが伝えたことを正しく実行するふりをします。 このプロジェクトには、HTTP APIをJavaコードでラップする別のモジュールがあります。 このモジュールは、独自のロジックをテストする単純なテストでテストされていますが、それだけでは十分ではありません。 さらに、2番目のグループでは、企業ネットワーク内でのみ実行される2、3のテストのみを実行し、この仮想コネクタが引き続き接続、仮想マシンの起動と終了、およびステータスの取得を行えることを確認します。 アプリケーションのロジックをテストする方がはるかに興味深く、便利です。 ここでスタブが役立ちます。 いつものように、ファウラーは私たちのすべてです。

 // VirtualInfrastructureManager -  ,     public class VirtualInfrastructureManagerStub implements VirtualInfrastructureManager { private List<VirtualMachineState> vms; public VirtualMachineState createVm(VirtualMachineDescription vmDescription) { vms.add(makeVm(vmDescription)); } public List<VirtualMachineState> pollForStatuses() { return vms; } //,   .   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、Springのマジックを使用して、テストコンテキストで、仮想インフラストラクチャが必要な場合はいつでもこのクラスを置き換えます。 さらに、すべてのテストで、仮想マシンが実際に作成されたかどうか、および作成時のアプリケーションの動作を確認しません。

 public void testDeploymentStarted() { Deployment deployment = DeploymentMother.makeNewDeployment(); deploymentManager.startDeployment(deployment); assertDeploymentGoesThroughStatuses(NEW, STARTING, CONFIGURING, RUNNING); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに興味深いものにするために、 Chaos Monkeyをスタブに追加できます。

 public class VirtualInfrastructureManagerStubWithChaosMonkey implements VirtualInfrastructureManager { private ChaosMonkey monkey; public VirtualMachineState createVm(VirtualMachineDescription vmDescription) { monkey.rollTheDice(); vms.add(makeVm(vmDescription)); } ... private class ChaosMonkey { public void rollTheDice() { if (iAmEvil()) throw new VirtualInfrastructureException("Ha-ha!"); return; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

猿にエラーの可能性を尋ねることができる場合、いくつの興味深い状況を作り出すことができるか想像してみてください。 または、彼女が定期的にランダムな法則で仮想マシンを「殺す」としたら？

 public void testRunningDeploymentRecovers() { Deployment deployment = startDeploymentAndAssertRunning(); ((VirtualInfrastructureManagerStubWithChaosMonkey)virtualInfrastructureManager) .getChaosMonkey().killVms(1); assertDeploymentGoesThroughStatuses(BROKEN, RECOVERING, RUNNING); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、企業のVPNに接続する必要もなく、各仮想マシンを起動するのに5分間待つことなく、この楽しさをすべてマシン上で直接取得できます。

余談：継続的インテグレーション

簡単に説明します。チームに複数の人がいる場合は、継続的な統合サーバーが必要です。 コードリポジトリと同じくらい必要です。 これらのスマートで美しいテストが実行され、エラーが検出されない場合、これらをすべて記述するポイントは何ですか？ このプロジェクトでは、3つの異なるアセンブリプロセスがありました。 1つ目は、誰かがgit pushを行うたびに自動的に開始され、最初のグループのテストを追跡します。 チームにはルールがありました。プッシュを行った場合、最初のビルドが成功するまで（約20分）家に帰りません。 一部のオフィスでは、豪華なゴキブリがアセンブリを壊した人のテーブルに置かれ、一部のオフィスでは、「キックミー、私はビルドを壊しました」という碑文の無次元の黄色のTシャツを着用する義務がありましたが、それは私たちにとって簡単でした。 最初のアセンブリが成功した場合、2番目のアセンブリが起動され、実際のインフラストラクチャで動作する2番目のグループからテストを実行しました。 このプロセスは非常に時間がかかりました（残念ながら）。 正常に終了した場合、3番目のアセンブリがオンになり、収集されたコードがテストサーバーにアップロードされ、アップグレードが成功したことを確認するために2、3回だけテストが実行されました。 この段階で、データベースの構造の変更に関する問題が発見されました。 3つのアセンブリすべての後、動作するコードが保証されたサーバーがあり、クライアントにそれを示すことができました。

アプリケーション全体をテストする

もちろん、これはすばらしいことですが、安らかに眠るには、個々のアプリケーションだけでなく、アプリケーションが完全に動作することを確認する必要があります。 さらに、個々のモジュールとその組み合わせがテストで十分にカバーされている場合、同じ作業を2回行わないように作業のすべての側面をチェックする必要はありません。 ここで、製品の技術仕様を再度参照すると便利です。 たとえば、ストーリーの1つ（ユーザーストーリー）には、「ユーザーとして、MySQLを必要とするアプリケーションをマスタースレーブレプリケーションモードで実行できるようにしたい」と書かれています。 アプリケーションのロードをチェックするテストがあります。すべてのケースで各仮想マシンに送信する情報の正確性を保証するテストがあります。 ただし、仮想マシンで必要なすべてのソフトウェアを構成するコード自体は、まず他の人が作成し、次に別の言語で作成します。 この場合、私たちは何をしますか？ 愚かな話の説明に従ってください。 「私のアプリケーションにはマスタースレーブが必要です」と書かれています-お願いします。 2つのJSPページで構成されるプリミティブWebアプリケーションを作成しています。 1ページで、マスターへのJDBCConnectionを作成し、特定のエントリをデータベースに書き込みます。 2番目のページで、スレーブへのJDBCConnectionを作成し、読み取ります。 このテストアプリケーションの作成に必要な時間は10分です。テストでは、このアプリケーションを製品に読み込み、目的のモードで実行するように要求し、HTTPで最初のページにアクセスしてから2番目のページにアクセスします。 目的のテキストが2ページ目に表示された場合-すべてが順調です。 要件のリストに創造的にアプローチする場合、そのような完全なテストはほとんど必要ありません。 しかし、仮想マシンを実行するために、他のいくつかのオペレーティングシステムのサポートを緊急に追加するように命じられたとき、これが大きな助けになることを想像してください！

Web UIテスト

これは完全に別のトピックであり、非常に興味深い、落とし穴があります。 説明されたプロジェクトでは行われなかったため、私は今それを開示し始めません。 インターフェイスはFlexで作成され、ゴキブリと別のグループによって処理されました。 私は抗議し、興味をそそり、できることをしましたが、何も変わりませんでした。 私自身は1年半前にまったく異なるプロジェクトでWebインターフェイスをテストしていましたが、今ではメモリからWebテストの良い例を提供するのは難しいでしょう。 私は、セレニウムがあなたの非常に大きな友人であるとしか言えません。 現在のプロジェクトをどのように完全にテストしたのでしょうか？ 特にこのために、一連のREST Webサービスを作成する必要があり、すべてのテストでそれらを呼び出しました。 私たちの最大の勝利は、Flexインターフェイスにこれらのサービスへのアクセスを強制したことだと思います。したがって、製品が機能していると確信しており、機能していない場合はインターフェイスの問題でした。 ちなみに、インターフェイスは常に機能が遅れているため、Webサービスにアクセスするコマンドライン用のクライアントを作成しました。このクライアントは潜在的なクライアントに非常に人気があり、当局はかつてWebインターフェイスを完全にスローしました。 しかし、これはまったく異なる話です。

おわりに

テストに関する教科書を書いたり、すべてのテストオプションを説明したりするタスクを自分で設定しませんでした。 テストの作成が必要であることを証明するために、もう二度と試みませんでした。 テストを書くことはまったく難しくなく、楽しいこともあるということを示したかっただけです（利点は言うまでもなく）。

• テストは「話す」必要があり、テスト自体は可能な限り原始的でなければなりません。 あなたは彼に何度も戻って来て、彼がチェックすべきことをもう一度理解しようとするでしょう。 ただコードを読むのに必要以上に時間がかかるべきではありません
• チームの最高のプログラマーは、複雑なものをテストするための便利なインフラストラクチャを作成および改善する必要があります。 たとえば、assertDeploymentGoesThroughStatuses（DeploymentStatus ... allowedStatuses）メソッドはまったく単純ではありません。 宿題は、アプリケーションがマルチスレッドであり、各ステップが個別のスレッドで実行され、無期限に時間がかかることを前提に、擬似コードでそのようなメソッドを記述することです:)
• テストする必要があるものだけをテストします。 ゲッターとセッターをチェックする20のテストを作成するには、手を離す必要があります
• コメントのどこかで、テストの構造を検討し、一般的に計画する必要があるという意見に出会いました。 私は断固として反対します。 テストを書く際の障壁は最小限に抑える必要があります。 テストを書き始めるだけです。 明日、構造を変更する必要がある場合は、変更してください。 リファクタリングは、他のすべてのものと同様にテストにも適用できます。
• 2回発生するテストの一部-別のメソッド（TestUtilsなど）に自由に入れてください。 これにより、スタッフが次のテストを書く際の障壁がさらに低くなります。
• 一般的すぎると思われるテスト（たとえば、TestUtilsのassertEquals（2、deployments.size（））（assertSize（expectedSize、collection））を取り出してください。
• コードの一部をテストするのが難しい場合は、おそらく不完全に記述されています。 原則として、最初にテストを作成してから、このテストをテストするコードを作成する必要があります。 それを試して、あなたはそれを好きになるでしょう。
• そして最も重要なことは、テストを書くことは退屈な義務ではなく、退屈なルーチンではなく、本当に興味深い問題について考えることができるコードを書くための正しいアプローチです。