0

私は今日、JUnitを使用してユニットテストを作成する非標準的な方法を見てきました。

フレームワークチェックを使用する代わりに

Assert.assertTrue("Unexpected response encoding", text.length() >= 1);

一般的な例外がスローされます

if (text.length() < 1) {
    throw new Exception("Unexpected response encoding");
}

最初のスタイルを採用するように作者を説得したいと思います。冗長性のような理由のほかに、意図の明確さは、これらのアプローチで他に何が異なる可能性があるかを知っていますか？

4

3 に答える 3

3

JUnitレポートでは、最初のスタイルは「失敗」として表示されますが、キャッチされない例外がスローされるため、2番目のスタイルは「エラー」として表示されます。

このタイプのラベリングを気にするかどうかによって異なり、完全に主観的ですが、個人的にはこれを「失敗」と見なしたいと思います。

于 2012-10-11T15:21:16.643 に答える
1

レポートでの彼らの扱いは2つの点で異なります。

  1. @Mattが述べたように、1つは失敗で、もう1つはエラーです。
  2. ImageneAssert.assertEqualsは、失敗すると、メッセージとともにレポートの値expectedと値の両方を報告します。found
于 2012-10-11T15:28:28.403 に答える
0

あなたの主な目標が誰かに2番目のアプローチよりも最初のアプローチを使用するように説得することであり、より多くの弾薬が必要な場合（私はあなたがより多くの弾薬を必要とすべきではないというJon Skeetのコメントに同意します）、テストコードに対してコードカバレッジツールを使用します。

優れた開発者は、単体テストを100％簡単にカバーできます。悪い開発者は、条件に入らなければ100％のカバレッジを得ることができませんif。いずれにせよ、あなたは悪い開発者をしつこくすることができます。なぜあなたのカバレッジは100％ではないのですか？または、なぜユニットテストに失敗するのですか？

それは公平ではありませんが、それは望ましい行動を動機付けるでしょう。

于 2012-10-11T16:47:39.227 に答える