Junit4: assertTrue()/assertFalse()는 기본적으로 오류 메시지를 포함해야 합니다.

이러한 기본 오류 메시지가 도움이 될까요? 어쨌든 무엇이 잘못되었는지 알아내려면 테스트 코드를 살펴봐야 하지 않을까요?

BTW 사용하십시오 org.junit.Assert 대신 junit.framework.Assert .

이 테스트를 작성한다고 가정해 보겠습니다.

사용자 사용자 = ...;
assertTrue(user.isHappy());
assertFalse(user.isSad());

테스트는 메시지 없이 AssertionError와 함께 실패합니다. 코드를 검사하고 어떤 주장이 실패한 줄 번호를 검사하지 않고는 알 수 있는 방법이 없습니다.

더 많은 데이터가 나쁜 이유는 무엇입니까?

더 많은 데이터가 나쁜 것은 아닙니다. 이 경우에는 더 많은 데이터만 볼 수 있습니다.

내가 이 기능 요청에 반대하는 것은 아니지만, Hamcrest 또는 Truth와 같이 오늘날 주장을 공식화하는 더 나은 방법이 있다고 생각합니다.

그럼에도 불구하고 누군가가 이 문제에 대한 pull 요청을 제출하면 아마도 병합할 것이라고 생각합니다... ;-)

@junit-team/junit-committers 이의가 있습니까?

나는 확실히 그것에 동의하지 않습니다 :-)
https://github.com/google/truth/commits?author=kluever

하지만 이 때문에 assertTrue/assertFalse 사용을 꺼리는 Google 직원이 있습니다. 하지만 확실히, 이에 대한 풀 리퀘스트를 보내겠습니다.

:웃다:

assertTrue 및 assertFalse 메시지를 제공할 수 있습니다.

assertTrue("The user is not happy, but she should.", user.isHappy());
assertFalse("The user is sad, but she should not.", user.isSad());

이 메시지는 스택 추적에 표시됩니다.

java.lang.AssertionError: The user is not happy, but she should.
java.lang.AssertionError: The user is sad, but she should not.

@stefanbirkner 네, 저도 잘 알고 있습니다. 하지만 기본 경우에도 합리적인 오류 메시지를 표시하지 않는 이유는 무엇입니까?

우리는 이미 assertEquals(expected, real)에 대해 이 작업을 수행하고 있습니다. 이렇게 하면 다음과 같이 작성할 필요가 없습니다.
assertEquals("예상 " + 예상 +" 하지만 " + 실제, 예상, 실제);

assertTrue()의 실패에 대한 더 나은 메시지가 유용할 수 있다는 데 동의하지만 "expected <true> but was <false>" 가 더 나은지 확실하지 않습니다.

@dsaff 는 역사적 맥락이 있다고 생각합니다.

문제의 범위를 명확히 하기 위해 "예상하지만"가 실제 추가 정보를 전달하기 때문이 아니라 일부 메시지에 대한 문체적 선호 때문에 '훨씬 더' 좋지 않습니까?

원래 디자인 생각은 오류 메시지를 구성하는 것이 당면한 문제에서 인지적 주의를 산만하게 하는 것이라는 것이었습니다. assertTrue(list.isEmpty())라고 하면 boolean 간의 비교 테스트가 아니라 list의 상태를 생각하는 것입니다. 따라서 JUnit은 말할 것도 없고 아무 말도 하지 않아야 합니다.

그것이 Chesterton의 울타리 뒤에 있는 이유입니다.

위에서 언급한 이 경우에는 여전히 흥미로운 데이터가 없습니다.

assertTrue(user.isHappy());
assertFalse(user.isSad());

assertEquals에 더 많은 정보를 제공하는 오류 메시지가 있는 이유는 더 많은 정보를 제공하기 때문입니다. 즉, 실제 값과 예상 값이 _are_이며 런타임까지 종종 알려지지 않기 때문입니다.

JUnit은 많이 사용되는 라이브러리이며, 이와 같은 사소한 변경조차도 핵심 메소드에 적용할 때 JUnit의 현재 동작에 의존하는 누군가의 테스트를 어딘가에서 중단시키는 경향이 있습니다. 나는 새로운 행동이 유용한 방식으로 다르다면 그렇게 하는 것이 좋지만 지금까지의 논거로는 유용성에 대해 확신하지 못한다.

현재 상태의 결과는 합리적이고 지능 개발자의 수는 항상 작성의 개인 연습을해야한다는 것입니다 assertEquals(true, expression()) 대신 assertTrue(expression()) . 게다가, 물론 리뷰어들에게 똑같이 하라고 요구하고 스타일 가이드에 넣는 등입니다. 우리가 코드 단순성을 좋아하기 때문에 슬프지만 그 숫자가 매우 높다고 주장할 수는 없다고 생각합니다.

나는 또한 David의 시작 질문(마지막 코멘트)에 대한 대답이 분명한 "예"라고 생각합니다. 실제 정보가 제공되는 유일한 경우는 테스트 메서드에 정확히 하나의 메시지 없는 assertTrue 와 정확히 하나의 메시지 없는 assertFalse 입니다. 그것은 매우 일반적이지 않습니다. 그리고 _그리고_ 스택 추적이 있고, _그리고_ 그들이 메시지를 제공했을 수도 있습니다... 그것은 많이 추가되지 않습니다. 나는 그것이 너무 _맨발로 나타나는 메시지 없는 예외와 관련이 있다고 생각합니다._

@junit-team/junit-committers 이 문제에 대해 어떻게 해야 합니까?

글쎄, 나는 그것을 닫는 데 찬성합니다. 케빈, 커트, 둘 다 변호인을 선임할 만큼 열성적입니까?

나는 그것을 닫는 것에 찬성합니다.

저는 이 문제에 찬성합니다. 다른 프레임워크는 실제 가치 기능 표시를 지원하며 필수적입니다. JUnit이 그렇게 융통성이 없다는 것이 믿기지 않았습니다.

assertTrue 및 assertFalse에 대해 보다 유익한 오류 메시지를 제공하는 것이 중요하기 때문에 이 문제에 찬성합니다. 제 동료와 저는 이 때문에 assertTrue/assertFalse 사용을 꺼립니다.

@ChaminW assertTrue("Some more specific message.", value); 를 사용하면 더 유익한 오류 메시지를 볼 수 있습니다.