問題タブ [junit]

@BeforeTestCase を拡張する JUnit 3 クラスがたくさんあり、それらを、@After、@Testなどの注釈を付けて JUnit4 テストに自動的に移行したいと考えて
います。大きなバッチ実行でこれを行うためのツールはありますか?

データベースに接続し、1 つ以上のクエリを実行し、結果を処理するコードの単体テストを書きたいと思います。（実際にデータベースを使用せずに）

ここにいる別の開発者は、xml 構成ファイルに基づいて対応するオブジェクトを返す独自の DataSource、Connection、Statement、PreparedStatement、および ResultSet 実装を作成しました。(偽のデータソースを使用して、それが返す結果セットに対してテストを実行するだけで済みます)。

ここで車輪を再発明していますか？このようなものは単体テスト用にすでに存在しますか? jdbcコードをテストするための他の/より良い方法はありますか?

実行に最も時間がかかるスイート内の junit テストを見つけるにはどうすればよいでしょうか? junitreport ant タスクのデフォルトの出力は役に立ちますが、私たちのスイートには何千ものテストが多数の小さなスイートに編成されているため、面倒であり、最悪の攻撃者は常に変化しています。

luntbuild を使用していますが、ant から実行できるものが理想的です。

私は Spring MVC プロジェクトに取り組んでおり、ソース ツリー内のさまざまなコンポーネントすべての単体テストを行っています。

たとえば、コントローラーHomeControllerを挿入する必要があるLoginService場合、単体テストではHomeControllerTest、オブジェクトを通常どおり (Spring の外部で) インスタンス化し、プロパティを挿入します。

これは、各コンポーネントを分離されたユニットとしてテストするのに最適です-プロジェクトに数十のクラスがあることを除いて、クラスを作成し、それに対して成功したユニットテストを作成した後、Spring MVC コンテキストファイルを更新するのを忘れ続けます展開されたアプリケーションでの実際の接続。プロジェクトを Tomcat にデプロイし、接続されていない Bean から多数の NullPointer を見つけたときに、コンテキスト ファイルを更新するのを忘れていたことに気付きました。

だから、ここに私の質問があります：

1. これは私の最初の Spring プロジェクトです。私が行ったように、個々の Bean の単体テストを作成してから、2 番目のテスト スイート (統合テスト) を作成して、すべてが実際のアプリケーション コンテキストで期待どおりに機能することをテストするのは正常ですか? これに対する確立されたベストプラクティスはありますか?

2. さらに、単体テストを統合テストからどのように分離しますか? すべてのソース コードはsrcにあり、ユニット テストはにあります。統合テスト ケース用にtest2 つ目のテスト フォルダ ( など) が必要ですか?test-integration

これは私の最初の Spring プロジェクトなので、他の人が通常この種のことをどのように行っているのか興味があります。車輪を再発明するのではなく、コミュニティの他のメンバーに尋ねます。

JUnit フレームワークには 2 つのAssertクラス (明らかに異なるパッケージ) が含まれており、それぞれのメソッドは非常に似ているように見えます。これがなぜなのか説明できる人はいますか？

私が参照しているクラスは次のとおりjunit.framework.Assertですorg.junit.Assert。

EMMAに問題があり、1つを除くすべてのさまざまなJavaプロジェクトを正しくカバーしています。ANTスクリプトが正しいように見えるのに、なぜこれが発生するのか、私は戸惑っています。次の期待される出力が与えられます。

上記は、次のANTスクリプトによって生成されます。

JUnitテストが実行された後、以下がログに記録されます。

emma.report：[レポート]入力ファイルを処理しています...
[レポート]16ミリ秒で読み取られてマージされた1つのファイル
[レポート]何もしません：どのデータファイルにもランタイムカバレッジデータが見つかりません

また、カバレッジレポートは生成されません。

Coverage.emmaファイルが正しくリンクされていると確信しているのに、EMMAがコードをカバーしていないのはなぜですか？

タスクは次のemma.reportようになります。

System.exit()特定の入力に対して呼び出すメソッドがいくつかあります。残念ながら、これらのケースをテストすると、JUnit が終了します。System.exit()現在のスレッドだけでなく JVM も終了するため、メソッド呼び出しを新しいスレッドに配置しても効果がないようです。これに対処するための一般的なパターンはありますか? たとえば、スタブを代用できSystem.exit()ますか?

[編集] 問題のクラスは、実際には JUnit 内でテストしようとしているコマンドライン ツールです。もしかしたら、JUnit は単にこの仕事に適したツールではないのでしょうか? 補完的な回帰テスト ツールの提案を歓迎します (できれば、JUnit および EclEmma とうまく統合されるもの)。

エグゼクティブ サマリー:スレッドでアサーション エラーがスローされても、単体テストは終了しません。あるスレッドが別のスレッドをクラッシュさせてはならないため、これは理にかなっています。問題は、1) 最初のヘルパー スレッドがクラッシュしたときにテスト全体を失敗させるか、2) ループしてすべてのスレッドが完了した後に各スレッドの状態を判断する方法です (以下のコードを参照)。後者を行う 1 つの方法は、スレッドごとのステータス変数、たとえば「boolean[] statuses」を使用し、「statuses[i] == false」をスレッドが失敗したことを意味するようにすることです (これは、より多くの情報を取得するために拡張できます)。ただし、それは私が望んでいることではありません。アサーション エラーがスローされたときに、他の単体テストと同じように失敗するようにしたいのです。これは可能ですか？それは望ましいですか？

うんざりしたので、単体テストで多数のスレッドを生成し、それらにサービス メソッドを呼び出させることにしました。コードはおおよそ次のようになります。

この後、スレッドの配列をループして、それぞれを開始します。その後、すべてが完了するのを待ちます。最後に、結果参照に対していくつかのチェックを実行します。

これが問題です。厄介な try-catch-throwable ブロックに気付きましたか? 何が起こっているのかを確認できるように、一時的なハックとして追加しました。runTest( String ) では、 assertNotNull( null ) など、いくつかのアサーションが作成されますが、別のスレッドにあるため、単体テストが失敗することはありません!!!!

私の推測では、どうにかしてスレッド配列を繰り返し処理し、それぞれのステータスをチェックし、スレッドが不適切な方法で終了した場合は手動でアサーション エラーを発生させる必要があると思います。この情報 (デッド スレッドのスタック トレース) を提供するメソッドの名前は?

A team member of mine recently setup some Hudson continuous-integration builds for a number of our development code bases. It uses the built in ant integration configured in simple way.

While, it is very helpful and I recommend it strongly, I was wondering how to get more more concise/informative/useful emails instead of just the tail of the ant build log.

E.G., Don't want this:

I assume, that I could skip the build-in ant support and send the build log through a grep script, but I was hoping there was a more integrated or elegant option.

私だけかもしれませんが、IntellijIdeaでのJunitテスト統合に関するドキュメントを理解できません。私が探しているのは、次のような簡単なチュートリアルの例です。これは2 + 2を計算するメソッドであり、これは4であるかどうかをテストするテストクラスです。これは、実行するために設定したチェックボックスです。ウェブ上またはIntellijIdeaヘルプ内にすでにそのようなものがある場合は、それを参照してください。Idea 7.0.4を使用しており、JUnit3.8または4.*を使用したいと思います。TIA。