10

約100の単体テストがあり、カバレッジは％20です。これは、カバレッジを拡大しようとしています。また、これは開発中のプロジェクトなので、新しいテストを追加し続けます。

現在、すべてのビルドの後にテストを実行することは実行可能ではなく、約2秒かかります。

テストに含まれるもの：

  • テストフォルダーから読み取られたファイル（一部のHTTPのものをシミュレートするためのデータ駆動型スタイル）
  • ローカルWebサーバーへの実際のHTTPリクエストの実行（これはモックするのに非常に苦痛なので、私はしません）
  • それらのすべてが単体テストではありませんが、テストする必要のある非常に複雑なマルチスレッドクラスもあり、テストの全体的な動作をテストします。これは機能テストと見なすことができますが、毎回実行する必要があります。

ほとんどの機能には、HTTPの読み取り、TCPの実行などが必要です。これらのテストを変更した場合、プロジェクトの全体像であるため、変更できません。テストを行うのは無意味です。

また、単体テストを実行するための最速のツールはないと思います。私の現在のセットアップでは、フレームワークとしてGallioとnUnitを使用したVSTSを使用しています。VS TS+Gallioも他のものより少し遅いと思います。

この問題を解決するために私に何を勧めますか？少しずつ変更した後に単体テストを実行したいのですが、現在この問題が私の流れを妨げています。

さらなる明確化編集：

コードは高度に結合されています！残念ながら、変更は巨大なrefatoringプロセスのようなものです。そして、そのような大きなコードをリファクタリングするために単体テストが必要な鶏卵症候群がありますが、それをリファクタリングしないと、これ以上単体テストを行うことはできません:)

高度に結合されたコードでは、テストを小さなチャンクに分割することはできません。また、私は個人的なものをテストしません。それは個人的な選択であり、それによって私は非常に速く開発し、それでも大きな利益を得ることができます。

そして、すべての単体テスト（適切な分離を使用）が実際に非常に高速であり、パフォーマンスの問題がないことを確認できます。

さらなる解明：

コードは高度に結合されています！残念ながら、変更は巨大なrefatoringプロセスのようなものです。そして、そのような大きなコードをリファクタリングするために単体テストが必要な鶏卵症候群がありますが、それをリファクタリングしないと、これ以上単体テストを行うことはできません:)

高度に結合されたコードでは、テストを小さなチャンクに分割することはできません。また、私は個人的なものをテストしません。それは個人的な選択であり、それによって私は非常に速く開発し、それでも大きな利益を得ることができます。

そして、すべての単体テスト（適切な分離を使用）が実際に非常に高速であり、パフォーマンスの問題がないことを確認できます。

4

6 に答える 6

13

これらは私には単体テストのようには聞こえませんが、機能テストのように聞こえます。それは問題ありません。機能テストを自動化することは良いことですが、機能テストが遅くなることはかなり一般的です。彼らはシステム全体（またはその大部分）をテストしています。

単体テストは、1つのものを他のすべてから分離してテストしているため、高速になる傾向があります。他のすべてから切り離してテストできない場合は、コーディングする警告サインが緊密に結合されていることを考慮する必要があります。

単体テスト（1つだけをテストする）と機能テスト（2つ以上を同時にテストする）のどちらのテストがあるかわかりますか？どれが速いのか、どれが遅いのか？

于 2008-12-15T15:06:32.213 に答える
8

テストを2つのグループに分割できます。1つは短いテスト用、もう1つは長時間実行テスト用で、変更のたびに短いテストを実行しながら、長時間実行テストを実行する頻度を減らします。それ以外に、Webサーバーからの応答やアプリケーションが行うその他の要求をモックすると、テストの実行時間が短くなります。

于 2008-12-15T15:07:11.760 に答える
8

あなたの問題に対する組み合わせたアプローチをお勧めします：

  • 変更を加えたコードに近いテストのサブセットを頻繁に実行します (たとえば、同じパッケージ、モジュールなどからのテスト)。現在取り組んでいるコードから離れた場所にあるテストを実行する頻度を減らします。
  • スイートを少なくとも 2 つに分割します: 高速実行テストと低速実行テスト。高速実行テストをより頻繁に実行します。
  • 失敗する可能性が低いテストのいくつかは、自動化された継続統合サーバーによってのみ実行されることを検討してください。
  • テストのパフォーマンスを向上させるテクニックを学びます。最も重要なのは、低速なシステム リソースへのアクセスを高速なフェイクに置き換えることです。たとえば、ファイルではなくメモリ ストリームで使用します。http アクセスをスタブ/モックします。等
  • (非常に強く推奨される) 本「レガシー コードを効果的に使用する」に記載されているような、リスクの低い依存関係を破る手法の使用方法を学びます。これらを使用すると、リスクの高いリファクタリングを適用することなく、コードを効果的にテストしやすくすることができます (多くの場合、テストのセーフティ ネットを使用してより良い設計にリファクタリングできるようになるまで、カプセル化を破るなど、実際の設計を一時的に悪化させます)。

上記の本から学んだ最も重要なことの 1 つは、魔法はなく、レガシー コードを操作することは苦痛であり、常に苦痛であり続けるということです。あなたにできることは、その事実を受け入れて、混乱からゆっくりと抜け出すために最善を尽くすことだけです.

于 2008-12-15T15:51:59.347 に答える
3

まず、それらは単体テストではありません。

小さな変更ごとにそのような機能テストを実行する意味はあまりありません。かなりの変更を行った後は、機能テストを実行する必要があります。

次に、アプリケーションの Http 部分をモックすることを恐れないでください。本当にアプリケーションの単体テストを行いたい場合は、MUST です。それをしたくない場合は、実際のロジックをテストしようとして、HTTP リクエストが戻ってくるのを待ってデータを設定しようとして、より多くの時間を無駄にすることになります。

統合レベルのテストは維持しますが、実際の単体テストの作成に努めます。これにより、速度の問題が解決されます。実際の単体テストには、DB との対話や HTTP との対話はありません。

于 2008-12-15T15:39:47.327 に答える
2

私は常に「LongTest」のカテゴリを使用しています。これらのテストは、日中ではなく毎晩実行されます。これにより、待ち時間を大幅に短縮できます。試してみてください: 単体テストを分類してください。

于 2008-12-15T15:42:37.837 に答える
1

開発チーム内の期待も管理する必要があるようです。

人々は 1 日に複数のビルドを行っており、各ビルドの後にテストを実行することが期待されていると思います。テスト スケジュールを変更して、昼休みにテストを含むビルドを実行し、その後夜に別のテストを実行するようにするとよいでしょう。

これらが機能テストのように聞こえるというブラッドの意見に同意します。コードを引き離すことができればそれは素晴らしいことですが、それまではあまり頻繁にテストしないことに切り替えます。

于 2008-12-15T15:43:55.603 に答える