Junit4: 機能強化：assertEquals（）のBigDecimalサポート

フォークやパッチとしてまとめるのは簡単でしょう。 必要に応じて喜んでやります。

assertEqualsにブールフラグを渡すよりも、assertNumericallyEqualToアサーションが必要です。

それはいい名前です。 私はそれをassertNumericallyEquals（）に短縮します。

私はその感情に同意しますが、別の名前の別のassertメソッドを使用することが、特に違いにまったく気付いていない、または実際に問題に遭遇したことがない人々の間で、混乱を解消するのに本当に役立つかどうかはわかりません。 つまり、この問題を読んでいなかったら、先に進んでassertEquals()をBigDecimal使用していたでしょう。 一般的なケースでは、実際には、宣伝どおりに機能します。つまり、 BigDecimal#equals()まったく同じように機能します。 これは良いことだと私は主張します。 BigDecimal#equals()価値と規模の両方を比較していることを誰かに認識させ、おそらくそれは彼らが達成しようとしていたことではなかったかもしれませんが、他の場合には、私はそれを主張します_は_。 つまり、場合によっては、メソッドによって返される実際の値が期待値と_正確に_ '等しい'（論理的/数値的に等しいだけでなく）ことを確認したい場合があります。 別の言い方をすれば、 assertNumericallyEquals()は（簡潔さは別として） assertEquals(0, actual.compareTo(expected))が提供しないものを提供しますか？ 個人的には、おそらくHamcrestマッチャーを作成し、必要に応じてassertThat(actual, isNumericallyEqualTo(expected))使用します。さらに、Hamcrestマッチャーを使用できる場所であればどこでも使用できます（データ検証など）。

計量が遅れて申し訳ありませんが、私の個人的な意見はAlistairの意見に近いものです。

別の言い方をすれば、 assertNumericallyEquals() 、（簡潔さは別として） assertEquals(0, actual.compareTo(expected))が提供しないものを提供しますか？

意図をより明確に伝えますか？ ハムクレストマッチャーのアプローチは私には問題ありません。

ジェフリー、

あなたはあなた自身のプロジェクトのためにそのマッチャーをうまく書いていると言っていますか、それともそれがハムクレストと一緒に出荷されることを望みますか？ またはJUnitですが、ハムクレストではありませんか？

上記のいずれかまたはすべて-私が書いたほとんどのプロジェクトには、カスタムのハムクレストマッチャーがいくつかあります。 HamcrestやJUnitで一般的なケースをカバーすることで、少し時間を節約できますが、これも私にとってあまり一般的なケースではありません。

あまり役に立たないエラーメッセージについての小さなポイント..BigDecimalsとAssert.assertEqualsの比較でヒットエラーが発生したAssert.assertEquals呼び出しをAssert.assertTrueに変換しました。 もちろん、現在、私のテストは、値が何であるかを教えてくれずに、一種の「ブールテストに失敗しました」というエラーで失敗します。 同様に、assertEquals（0、actual.compareTo（expected））は、assertNumericallyEquals（actual、expected）からのはるかに有用なエラーメッセージが「expected12.45 but got：1」である場合、たとえば「expected 0 but got：1」をログに記録します。 ：123 "（ 'actual'および 'expected'引数の実際の値）。

http://www.bssd.eu/blog/?p=113も興味深い読み物になります。

https://github.com/KentBeck/junit/pull/228のassertEquivalentがこれを解決するはずです。

dsaffに感謝します。 その作品は素晴らしく見えます。 これは以前に行ったことがありません。これは、junitソースをフェッチし、このプルリクエストを自分でマージして、カスタムビルドを作成する必要があることを意味しますか？

http://help.github.com/send-pull-requests/のヘルプから、次のようにする必要があるようです。

git clone https://github.com/KentBeck/junit.git
cd junit

次に、プルリクエスト用のリモートを追加してから、フェッチ、マージ、またはその両方を実行します。

これはプルリクエスト、つまり公式のjunitではないように思われるので、アプリケーションで使用するのが賢明ですか？ これがメインのjunitの外で成形される可能性があり、コードがビルドされない他のユーザーにコードを送信する際に問題が発生しますか？

ニークフェンウィック、

うん、あなたは今それを行う方法について正しい軌道に乗っています。 そのプルを4.10ブランチにマージするつもりですが、元の作成者はgitステータスをマージ可能にするのに問題がありました。 世界に恩恵をもたらす時間があれば、KentBeckリポジトリをフォークし、すべてをマージして、4.10ブランチに対してプルリクエストを発行することができます。そうすれば、誰にとっても簡単になります（人気があるように思える場合は、スピンすることもできます）。いつか4.10プレビューjarをアップします）。

私は本当に前にこれをやったことがない:)私はレポをフォークしてきたようにクローン化[email protected] ：私のローカルマシンにneekfenwick / junit.git（私はすでにgithubのアカウントを持っているとsshキーが設定）、および追加私がフォークしたリポジトリのリモート：

git remote add upstream https://github.com/KentBeck/junit.git

念のため、プルリクエストをHEAD以外の場所にマージできるように分岐しました。

git branch merge_pullreq_228
git checkout merge_pullreq_228

これで、私が見つけたドキュメントには、「プルリクエストをブランチにマージする」と書かれています。 https://github.com/KentBeck/junit/pull/228/commitsでプル228のコミットを確認できますが、マージできません。

[neek junit (merge_pullreq_228)]$ git merge 57b49344
fatal: '57b49344' does not point to a commit

プルリクエストは自分のリポジトリ/ブランチ用ではないため、github web gui（AFAIK）のマージツールを使用できません。

7つのコミットを自分のブランチにマージしてユニットテストをビルド/合格させたいと思っているのは正しいですか？ これらのコミットの1つをマージして、私を途中で進めるために何をすべきかを詳しく説明していただけますか？

そうです、Webマージツールを使用することはできません。 私がうまくいくと信じていることは次のとおりです。

git remote add leet3lite https://github.com/leet3lite/junit.git

そして、あなたのブランチから、

git pull leet3lite master

残念ながら、「電話で」gitを使用する方法を説明するとき、私は通常1つのことを忘れているので、それがうまくいくかどうか教えてください。

ああ、なるほど、これらのコミットのそれぞれをマージする必要はありません。leet3liteのマスターブランチにはすでにそれらがあります。問題は、元のマスターにマージする行為です。

そのブランチとHEADの間にマージの競合があるようです。 それがこの演習の要点だと思います。

[neek junit (merge_pullreq_228)]$ git remote add leet3lite https://github.com/leet3lite/junit.git
[neek junit (merge_pullreq_228)]$ git pull leet3lite master
remote: Counting objects: 100, done.
remote: Compressing objects: 100% (39/39), done.
remote: Total 85 (delta 34), reused 77 (delta 26)
Unpacking objects: 100% (85/85), done.
From https://github.com/leet3lite/junit
 * branch            master     -> FETCH_HEAD
Auto-merging acknowledgements.txt
CONFLICT (content): Merge conflict in acknowledgements.txt
Auto-merging src/main/java/org/junit/Assert.java
Auto-merging src/test/java/org/junit/tests/AllTests.java
CONFLICT (content): Merge conflict in src/test/java/org/junit/tests/AllTests.java
Automatic merge failed; fix conflicts and then commit the result.
[neek junit (merge_pullreq_228|MERGING)]$ 

それがあなたにとって理にかなっているように見えるなら、私はこれを明日続けることを検討します。 ここはほぼ真夜中です。

それはあなたが正しい場所にいるように見えます。 Acknowledgements.txtとAllTests.javaは、通常は追加だけで多くの人に影響を与えるため、マージ操作はおそらく、両方のパスに追加されたすべての行を含めるという単純な行為です。

これを推進してくれてありがとう。

これは2年前に修正されたと思います。

dsaff - No...?

4.11にはありません;（私もこの機能が必要です

assertEquivalent()に関する議論は＃228に移り、その後、＃376に移ったと思います。そこで、本当にHamcrestがこれを解決する必要があると判断しました。

@ junit-team / junit-committersこれを閉じることに異議はありますか？

私の側からの異議はありません。

おっと、フロイトのクリック。 :-)ここに異議はありません。

わかった。 その後、締めくくります。

ハムクレストマッチャーを使用してもこの問題が修正されるとは思いません。 たとえば、次のコード：

   assertThat(product.getRating(), is(equalTo(new BigDecimal("2.3"))));

この結果が生成されます：

Expected: is <2.3>
     but: was <2.30000>

junitまたはhamcrestにはまだisNumericEquivalentメソッドが必要だと思います。

comparesEqualToを使ってみましたか？

はい、 comparesEqualTo実際に機能します。 ありがとう。

これが私が少し前に作成したチートシートです：
http://www.marcphilipp.de/blog/2013/01/02/hamcrest-quick-reference/