私は、Eclipseで開発され、バンドルされ、Java 1.6を使用してJBossにデプロイされたさまざまなmavenモジュールを使用して、既存のJava EEプロジェクトに取り組んでいます。フレームワークを準備し、単体テストをプロジェクトに導入する方法を文書化する機会があります。
何かアドバイスいただけないでしょうか...
他に何か？前もって感謝します。
単体テスト フレームワークに関しては、主に jUnit と TestNG の 2 つがあります。どちらにも利点があり、どちらも同等のパフォーマンスを発揮します。jUnit の主な利点は、(私の考えでは) デフォルトで Eclipse プラグインが組み込まれており、簡単にテストを呼び出すことができることです。
モック フレームワークに関しては、それらがテスト アプローチの必須部分であるとは思いません。もちろん、それらは便利ですが、特定の目的を解決します: 動作のテスト (インターフェイスのテストとは対照的に - jUnit が許可するもの)。モッキング フレームワークを使用すると、特定のクラスが特定のインターフェイスをどのように実装するかをテストできます。必要ですか? もちろんです.最初にそれが必要ですか?わかりません.
ルールに関して、有用であるとわかった唯一のルールは (いつものように) シンプルです: 「少なくとも 1 回は壊れたコードを常にテストする」。バグトラッカーを検討してください。バグが発生するたびに、回帰がないことを確認する単体テストが必要です。私の考えでは、これは高品質のコードを作成するためのより高速な方法です。
ファンシーで効率的な出力に関しては、継続的インテグレーション サーバー (明らかにHudson ) をインストールすることをお勧めします。副作用がないことを確認するために、コードがコミットされるたびにすべてのテスト スイートが実行されます。テスト実行回数などを示すグラフを生成します。また、コード カバレッジ ツールとグラフを統合することもできます。この継続的インテグレーション サーバーは、本当に高速なテスト バディになります。
これは複雑な質問なので、$work での私たちの慣習についていくつかメモしておきます。
プロジェクト マネージャーがこびへつらうための派手な出力を生成するツールはありますか?
気をつけて。単体テスト数、カバレッジ、コード品質指標、行数、チェックイン数などの指標を表示するための派手なツールは、一部のプロジェクト マネージャーの手に渡ると危険な場合があります。プロジェクト マネージャー (ソフトウェア開発の現実に触れていない) は、メトリクスに夢中になり、次のことに気付かないことがあります。
プロジェクトの健全性と進捗状況を正確に把握していない。
個々のチームメンバーのパフォーマンスについて、完全に誤ったイメージを与える可能性があります。
マネージャーが開発者に、(たとえば) 単純に保証されていないコードの単体テスト カバレッジを最大限に達成するように努めるべきであるというメッセージを与えるというばかげた状況が発生する可能性があります。無意味な仕事に時間を費やし、重要な仕事を終わらせず、締め切りを守らない。
設定する必要があるルール - コード カバレッジ、または統合テストではなくユニットであることの確認。
コード カバレッジは、壊れやすい/バグがある可能性が高いコードの部分にとってより重要です。ベンチマーク カバレッジ レベルを強制しないでください。
単体テストと統合テストは、構築しているシステムの性質と複雑さによって異なります。
事後的に多くの単体レベルのテストを追加するのは、おそらく時間の無駄です。問題がある/メンテナンス作業が必要であると識別されたクラスに対してのみ実行する必要があります。
事後に統合レベルのテストを追加することは、特にプロジェクトの元の開発者がもういない場合に役立ちます。適切な統合テスト スイートは、一部の変更によって重要なシステム機能が損なわれないという確信を高めるのに役立ちます。しかし、これは慎重に行う必要があります。Web サイトのルック アンド フィールの N 度をテストするテスト スイートは、維持するのは悪夢であり、進歩の妨げになる可能性があります。
まだ読んでいない場合は、 Michael FeathersによるWorking Effectively with Legacy Code を読んでください。
単体テストを C++ プロジェクトに改造してきましたが、快適ではありません。
私が最初にしたことは、ほとんどの「アクション」が発生する場所を特定することでした。次に、それを使用して、簡単にテストできる関数に単体テストを配置し始めます。
次に、より簡単なものができたら、カバレッジをバイラルに拡大することを検討できます。依存関係が少ない関数を攻撃し、デバッガーでそれらを数回実行して、渡される値を確認し、それらの値を使用して単体テストを記述して、何も壊さないように。
迅速な修正を期待しないでください - 20% のカバレッジを得るのに 3 週間 (1 日 6 時間、週 5 日) かかりますが、コードはそのコードに 80% の時間を費やしているので、十分に時間を費やして発見したと思います。かなりの数のバグ。
テスト カバレッジに関しては、既存のプロジェクトに単体テストを導入する場合、カバレッジの期待値を設定し始めるのは時期尚早だと思います。テスト フレームワークを実際に統合し、カバレッジ ツールからレポートを取得できることを確認することから始める必要があります。それが完了したら、カバレッジの監視を開始できます。次に、ターゲットを検討できます。