Junit4: 향상: assertEquals()에 대한 BigDecimal 지원

포크나 패치로 쉽게 결합할 수 있습니다. 적절하다면 기꺼이 하겠다.

assertEquals에 부울 플래그를 전달하는 것보다 assertNumericallyEqualTo 어설션을 사용하고 싶습니다.

좋은 이름입니다. assertNumericallyEquals()로 줄이겠습니다.

나는 그 의견에 동의하지만 다른 이름을 가진 다른 assert 메서드를 사용하는 것이 특히 차이점을 완전히 알지 못하거나 문제를 직접 경험하지 않은 사람들 사이에서 혼란을 해결하는 데 실제로 도움이 될지 확신할 수 없습니다. 내 말은, 이 문제를 읽지 않았다면 assertEquals() 대해 BigDecimal assertEquals() 를 사용했을 것입니다. 일반적인 경우 실제로 광고한 대로 작동합니다. BigDecimal#equals() 작동 방식과 정확히 일치합니다. 나는 이것이 좋은 일이라고 주장하기도 합니다. 누군가 BigDecimal#equals() 가치와 규모를 모두 비교한다는 사실을 깨닫게 된다면 그것이 그들이 성취하려고 했던 것이 아닐 수도 있습니다. 그러나 다른 경우에는 그렇게 생각합니다. _이다_. 내 말은, 어떤 경우에는 메서드에서 반환된 실제 값이 예상 값과 _정확히_ '동일'한지 확인하려는 경우가 있습니다(논리적으로/숫자적으로만 동일한 것이 아님). 다른 식으로 말하면 assertEquals(0, actual.compareTo(expected)) 가 제공하지 않는 assertNumericallyEquals() 가 (간결함을 제외하고) 무엇을 제공합니까? 개인적으로 저는 Hamcrest 매처를 만들고 자주 필요할 경우 assertThat(actual, isNumericallyEqualTo(expected)) 로 이동할 것입니다. 게다가 Hamcrest 매처를 사용할 수 있는 모든 곳에서 사용할 수 있습니다(특히 데이터 유효성 검사).

늦은 체중 측정에 대해 죄송하지만 제 개인적인 의견은 Alistair에 가깝습니다.

다르게 표현하자면 assertNumericallyEquals() 는 assertEquals(0, actual.compareTo(expected)) 가 제공하지 않는 (간결함을 제외하고) 무엇을 제공합니까?

의도를 더 명확하게 전달합니까? hamcrest matcher 접근 방식은 저에게 좋습니다.

제프리,

자신의 프로젝트를 위해 그 matcher를 잘 작성하고 있다는 말입니까, 아니면 hamcrest와 함께 제공되기를 원하십니까? 또는 JUnit이 있지만 햄크레스트는 아닌가요?

위의 일부 또는 모두 -- 내가 작성하는 대부분의 프로젝트는 결국 일부 사용자 지정 햄크레스트 매처를 갖게 됩니다. Hamcrest 및/또는 JUnit으로 일반적인 경우를 처리하면 시간이 조금 절약되지만 이것은 저에게 그다지 흔한 경우는 아닙니다.

덜 유용한 오류 메시지에 대한 작은 요점. BigDecimal을 Assert.assertEquals와 비교하는 데 실패하여 Assert.assertEquals 호출을 Assert.assertTrue로 변환했습니다. 물론 이제 내 테스트는 값이 무엇인지 알려주지 않고 일종의 "부울 테스트 실패" 오류와 함께 실패합니다. 같은 방식으로 assertEquals(0, actual.compareTo(expected))는 훨씬 더 유용한 오류 메시지가 assertNumericallyEquals(actual, expected)에서 "12.45를 예상했지만 : 123"('실제' 및 '예상' 인수의 실제 값).

http://www.bssd.eu/blog/?p=113 도 흥미롭게 읽을 수 있습니다.

https://github.com/KentBeck/junit/pull/228의 assertEquivalent가 이 문제를 해결해야 합니다.

감사합니다. 그 작품은 멋져 보인다. 나는 전에 이것을 해본 적이 없는데, 이것은 내가 junit 소스를 가져와야 하고, 이 pull 요청을 직접 병합하고, 사용자 정의 빌드를 만들어야 한다는 것을 의미합니까?

http://help.github.com/send-pull-requests/ 의 도움말에서 다음과 같이 해야 합니다.

자식 클론 https://github.com/KentBeck/junit.git
CD 주니트

그런 다음 pull 요청에 대한 리모컨을 추가한 다음 가져오기, 병합 또는 둘 다를 수행합니다.

이것이 공식 junit이 아닌 pull request인 것을 감안할 때 애플리케이션에서 사용하는 것이 현명합니까? 이것이 주요 junit 외부에서 변형될 가능성이 있으며 빌드하지 않을 다른 사람에게 내 코드를 보내는 데 문제가 있습니까?

네크펜윅,

네, 지금 방법에 대해 올바른 길을 가고 있습니다. 나는 그 풀을 4.10 브랜치에 병합하려고 하지만 원래 작성자는 git 상태를 병합할 수 있게 하는 데 문제가 있었습니다. 세상에 호의를 베풀 시간이 있다면 KentBeck 리포지토리를 포크하고 모든 것을 병합하고 4.10 브랜치에 대해 풀 리퀘스트를 발행하여 모두에게 더 쉽게 만들 수 있습니다. 언젠가는 4.10 미리보기 병으로).

나는 정말로 이것을 한 적이 없습니다. :) 그래서 나는 repo를 분기하고 [email protected] :neekfenwick/junit.git을 내 로컬 컴퓨터에 복제

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 에서 pull 228에 대한 커밋을 볼 수 있지만 병합할 수는 없습니다.

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

pull 요청은 내 자신의 repo/branch에 대한 것이 아니므로 github web gui(AFAIK)에서 Merge 도구를 사용할 수 없습니다.

내 자신의 분기에 7개의 커밋을 병합하고 단위 테스트를 빌드/통과하기를 원한다고 생각하는 것이 맞습니까? 이 커밋 중 하나를 병합하기 위해 무엇을 해야 하는지 설명해 주시겠습니까?

맞습니다. 웹 병합 도구를 사용할 수 없습니다. 효과가 있다고 생각하는 것은 다음과 같습니다.

자식 원격 추가 leet3lite https://github.com/leet3lite/junit.git

그런 다음 지점에서 전화하십시오.

git pull leet3lite 마스터

불행히도, git을 "전화로" 사용하는 방법을 설명할 때 보통 한 가지를 잊어버리므로 그것이 당신에게 적합한지 알려주세요.

아 알겠습니다. 각 커밋을 병합할 필요가 없습니다. 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 내가 이것을 닫는 것에 대해 이의가 있습니까?

내 쪽에서 반대가 없습니다.

이런, Freudian 클릭. :-) 여기에는 이의가 없습니다.

괜찮아. 닫습니다.

hamcrest matcher를 사용하여 이 문제를 해결할 수 있다고 생각하지 않습니다. 예를 들어 다음 코드:

   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/