25

何か知りたいのですが、テストを簡単にするために、単体テスト中にモックを使用して、外部依存関係なしで必要なコンポーネントのみをテストする必要があることを知っています。しかし、ある時点で、データベース、ファイル、ネットワークなどとやり取りするクラスを徹底的にテストする必要があります。

私の主な質問は、これらのクラスをテストするために何をしますか?

  • CI サーバーにデータベースをインストールするのは良い方法だとは思いませんが、他に選択肢はありますか?

  • すべての外部依存関係を使用して、他の CI ツールを使用して別のサーバーを作成する必要がありますか?

  • 単体テストと同じくらい頻繁に CI で統合テストを実行する必要がありますか?

  • これらのコンポーネントを手動でテストするには、フルタイムの担当者が担当する必要があるのではないでしょうか? (または、アプリケーションの構成ファイルの編集など、テスト環境を作成し、クラスと外部依存関係の間の相互作用を構成する責任があります)

現実世界でどう過ごしているのか知りたいです。

4

4 に答える 4

20

私はあなたが現実の世界でどのようにやっているか知りたいですか？

現実の世界では、何をすべきかについて簡単な処方箋はありませんが、指針となる真実が 1 つあります。それは、ミス/バグ/テストの失敗が発生したら、できるだけ早くそれらを見つけたいということです。それをガイドにしましょう。それ以外はテクニックです。

いくつかの一般的なテクニック:

  • 並行して実行されるテスト。これは私の好みです。私は 2 つのシステムが好きで、それぞれが CruiseControl* の独自のインスタンス (私がコミッターを務めています) を実行し、1 つは高速フィードバック (< 5 分) で単体テストを実行し、もう 1 つのシステムは統合テストを継続的に実行します。チェックインが発生してからシステム テストで検出されるまでの遅延が最小限に抑えられるので、私はこれが気に入っています。一部の人々が好まない欠点は、単体テストの失敗と統合テストの失敗の両方で、同じチェックインに対して複数のテスト失敗が発生する可能性があることです。これは実際には大きな欠点ではありません。

  • 単体テストに合格した後にのみシステム/統合テストが実行されるライフサイクル モデル。この種のモデルを中心に構築された AnthillPro* のようなツールがあり、このアプローチは非常に人気があります。彼らのモデルでは、単体テストに合格した成果物を取得し、それらを別のステージング サーバーにデプロイしてから、そこでシステム/統合テストを実行します。

このトピックについてさらに質問がある場合は、Continuous Integration and Testing Conference (CITCON) および/またはCITCON メーリング リストをお勧めします。

于 2009-02-06T17:29:57.647 に答える
5

私がよく目にするアプローチは、チェックイン時にすぐに単体テストを実行し、一定の間隔でより長い統合テストを実行することです (おそらく別のサーバーで実行します。それは実際には好み次第です)。また、統合テストが「短時間実行」統合テストと「長時間実行」統合テストに分割され、異なる間隔で実行されることも確認しました (たとえば、「短時間実行」テストは 1 時間ごとに実行され、「長時間実行」テストは「長時間実行」テストです)。 -running" テストは夜間に実行されます)。

自動化されたテストの真の目標は、可能な限り迅速にフィードバックを開発者に提供することです。そのことを念頭に置いて、できるだけ頻繁に統合テストを実行する必要があります。統合テストの実行時間に大きなばらつきがある場合は、より高速な統合テストをより頻繁に実行し、より遅い統合テストをより頻繁に実行する必要があります。テストのセットを実行する頻度は、すべてのテストを実行するのにかかる時間と、テストの実行が実行時間の短いテスト (単体テストを含む) をどれだけ混乱させるかによって異なります。

これですべての質問に答えられるわけではないことは承知していますが、スケジューリングの部分についていくつかのアイデアが得られることを願っています.

于 2009-02-05T17:30:39.817 に答える
4

統合テストの実際の性質によっては、実行前に少なくとも 1 回再作成される組み込みデータベース エンジンを使用することをお勧めします。これにより、異なるコミットのテストを並行して実行できるようになり、テストの開始点が明確に定義されます。

ネットワーク サービスは、定義上、別の場所にインストールすることもできます。

ただし、CI マシンを開発環境や本番環境から分離しておくために、常に細心の注意を払ってください。

于 2009-02-05T17:26:33.537 に答える
1

お使いのプラットフォームの種類はわかりませんが、Java を使用しています。私が働いている場所では、JUnit で統合テストを作成し、Spring のような DI コンテナーを使用して適切な依存関係を注入します。それらは、開発者自身 (通常は小さなサブセット) と CI サーバーの両方によって、実際のデータ ソースに対して実行されます。

私の意見では、統合テストを実行する頻度は、実行にかかる時間によって異なります。できるだけ頻繁に実行してください。実在の人物をここから除外し、テストを自動化するのが困難またはコストがかかりすぎる領域 (たとえば、スペル、さまざまな GUI コンポーネントの位置) で手動システム テストを実行させます。構成ファイルの編集はマシンに任せます。私が働いている場所では、コンピューターにシステム変数 (DEV、TEST など) を設定し、それに基づいてアプリに構成ファイルを選択させています。

于 2009-02-05T17:31:16.867 に答える