何か知りたいのですが、テストを簡単にするために、単体テスト中にモックを使用して、外部の依存関係なしに、必要なコンポーネントのみをテストする必要があることを知っています。しかし、ある時点で、データベース、ファイル、ネットワークなどと相互作用する弾丸とテストクラスを噛む必要があります。
私の主な質問は、これらのクラスをテストするために何をしますか?
CIサーバーにデータベースをインストールすることは良い習慣だとは思いませんが、他に選択肢はありますか?
すべての外部依存関係を使用して、他のCIツールを使用して別のサーバーを作成する必要がありますか?
単体テストと同じ頻度でCIで統合テストを実行する必要がありますか?
たぶん、フルタイムの人がこれらのコンポーネントを手動でテストする責任があるべきですか? (または、テスト環境を作成し、アプリケーションの構成ファイルの編集など、クラスと外部依存関係の間の相互作用を構成する責任があります)
実社会でどうやってやっているのか知りたいのですが。
実社会でどうやってやっているのか知りたいのですが?
現実の世界では、何をすべきかについての簡単な処方箋はありませんが、1つの指針となる真実があります。それは、間違い/バグ/テストの失敗が導入された後、できるだけ早くキャッチしたいということです。それをあなたのガイドにしましょう。他のすべては技術です。
いくつかの一般的なテクニック:
並行して実行されるテスト。これが私の好みです。私は2つのシステムが好きです。それぞれがCruiseControl *の独自のインスタンス(私はコミッターです)を実行し、1つは高速フィードバック(<5分)で単体テストを実行し、もう1つのシステムは統合テストを常に実行します。チェックインが発生してからシステムテストで検出されるまでの遅延が最小限に抑えられるため、これが気に入っています。一部の人が気に入らない欠点は、単体テストの失敗と統合テストの失敗の両方で、同じチェックインに対して複数のテストが失敗する可能性があることです。実際には、これが大きなマイナス面だとは思いません。
単体テストに合格した後にのみシステム/統合テストが実行されるライフサイクルモデル。この種のモデルを中心に構築されたAnthillPro *のようなツールがあり、このアプローチは非常に人気があります。彼らのモデルでは、単体テストに合格したアーティファクトを取得し、それらを別のステージングサーバーに展開して、そこでシステム/統合テストを実行します。
このトピックについてさらに質問がある場合は、 継続的インテグレーションおよびテスト会議 (CITCON)および/または CITCONメーリングリスト をお勧めします。
統合テストの実際の性質に応じて、実行前に少なくとも1回は再作成される組み込みデータベースエンジンを使用することをお勧めします。これにより、さまざまなコミットのテストを並行して実行できるようになり、テストの開始点が明確に定義されます。
ネットワークサービスは、定義上、別の場所にインストールすることもできます。
ただし、CIマシンを開発環境や製品環境から分離しておくために、常に十分に注意してください。
私が最も頻繁に採用しているアプローチは、チェックイン時にすぐに単体テストを実行し、一定の間隔でより長い統合テストを実行することです(おそらく別のサーバーで、それは本当にあなたの好み次第です)。また、統合テストが「短期」統合テストと「長期」統合テストに分割され、異なる間隔で実行されることもあります(たとえば、「短期」テストは1時間ごとに実行され、「長期」テストは-実行中の」テストは一晩実行されます)。
自動テストの本当の目標は、可能な限り迅速に開発者にフィードバックを得ることにあります。そのことを念頭に置いて、できるだけ頻繁に統合テストを実行する必要があります。統合テストの実行時間に大きなばらつきがある場合は、より速い統合テストをより頻繁に実行し、より遅い統合テストをより頻繁に実行する必要があります。テストのセットを実行する頻度は、すべてのテストの実行にかかる時間と、実行時間の短いテスト(単体テストを含む)に対するテストの実行の中断度によって異なります。
これですべての質問に答えることはできないと思いますが、スケジューリングの部分についていくつかのアイデアが得られることを願っています。
使用しているプラットフォームの種類はわかりませんが、Javaを使用しています。私が働いている場所では、JUnitで統合テストを作成し、SpringなどのDIコンテナーを使用して適切な依存関係を注入します。これらは、開発者自身(通常は小さなサブセット)とCIサーバーの両方によって、実際のデータソースに対して実行されます。
私の意見では、統合テストを実行する頻度は、実行にかかる時間によって異なります。できるだけ頻繁に実行してください。実在の人物をこれから除外し、テストを自動化するのが困難または高すぎる領域(たとえば、スペル、さまざまなGUIコンポーネントの位置)で手動のシステムテストを実行できるようにします。設定ファイルの編集はマシンに任せてください。私が働いている場所では、コンピューターにシステム変数(DEV、TESTなど)を設定し、それに基づいてアプリに構成ファイルを選択させます。