JUnit 메시지에 성공 또는 실패 조건이 명시되어야합니까?

JUnit 메시지에 성공 또는 실패 조건이 명시되어야합니까?

---

두 가지 방법 중 하나로 어설 션 메시지를 작성할 수 있습니다. 성공 진술 :

assertEquals( "objects should be identical", expected, actual );

또는 파손 된 상태를 명시하십시오.

assertEquals( "objects aren't identical", expected, actual );

특별히 JUnit에 이에 대한 표준이 있습니까? 그렇지 않다면 양측의 주장은 무엇입니까?

추신 웹에서이 두 가지를 설명없이 시연하는 기사를 보았습니다. "Google 검색"이라고 말하는 것만으로는 답이 아닙니다!

[최신 정보]

내가 사용한 사실에 모든 사람들이 끊기고 assertEquals있으므로 메시지는 아마도 쓸모가 없을 것입니다. 하지만 당연히 질문을 간단히 설명하고 싶었 기 때문입니다.

대신 다음과 같이 상상해보십시오.

assertTrue( ... big long multi-line expression ... );

메시지가 유용한 곳.

---

나는 적어도 assertEquals. 현명한 테스트 실행자는 당신이 사용 assertEquals하고 있다는 것과 동등하다는 두 가지를 설명합니다 . 귀하의 메시지 중 어느 것도 그보다 더 많은 정보를 제공하지 않습니다.

일반적으로 단위 테스트 실패는 일시적인 것임을 알게됩니다. 무엇이 잘못되었는지 신속하게 찾아서 고칠 것입니다. "무엇이 잘못되었는지 찾아내는 것"은 일반적으로 하나의 메시지가 큰 차이를 만들지 않을 정도의 세부 사항을 포함합니다. "메시지를 통해 절약 된 시간"과 "메시지를 생각하는 데 소요 된 시간"을 고려하십시오. :)

편집 : 좋아, 내가 메시지를 사용할 수 있는 한 가지 경우 : 개체의 문자열 표현에서 명확하지 않은 텍스트에 간결한 설명이있을 때.

예 : 밀리 초로 저장된 날짜를 비교할 때 "예상 날짜는 12 월 1 일"입니다.

나는 당신이 그것을 정확하게 표현하는 방법에 대해 걱정하지 않을 것입니다. 단지 당신이 의미하는 방식이 메시지에서 분명한지 확인하십시오. "해야한다"또는 "그렇지 않았다"는 것은 괜찮습니다. 단지 "12 월 1 일"은 분명하지 않을 것입니다.

---

junit API에 따르면 메시지는 "AssertionError에 대한 식별 메시지"이므로 충족해야하는 조건을 설명하는 메시지가 아니라 조건이 충족되지 않은 경우 무엇이 잘못되었는지 설명하는 메시지입니다. 따라서 귀하의 예에서 "객체가 동일하지 않습니다"가 더 순응적인 것처럼 보입니다.

---

다른 많은 사람들과 달리 저는 메시지를 사용하는 것이 여러 가지 이유로 매우 도움이된다고 생각합니다.

1. 실패한 테스트의 로그를 보는 사람은 테스트를 작성한 사람이 아닐 수 있습니다. 코드를 읽고 어설 션이 처리해야하는 경우를 이해하는 데 시간이 걸릴 수 있습니다. 유용한 메시지는 시간을 절약 할 것입니다.

2. 로그를보고있는 사람이 테스트 개발자 인 경우에도 테스트가 작성된 후 며칠 또는 몇 달이 걸렸을 수 있으며 메시지를 통해 시간을 절약 할 수 있습니다.

내 조언은 예상되는 행동에 대한 설명과 함께 메시지를 작성하는 것입니다. 예를 들면 :

assertEquals("The method should be invoked 3 times", 3, invocationCount);

---

나는 그것이 전혀 중요하지 않다고 생각합니다. 당신은 이미 실패가 발생했다는 것을 알고 있기 때문에 메시지에 무슨 일이 일어 났어 야하는지, 아니면 일어나지 말아야하는지 여부는 중요하지 않습니다.

메시지의 목표는 완전성을 얻기위한 것이 아니라 가능할 때 도움을주는 것입니다.

분명히 assertEquals의 경우에는 덜 중요하지만 일반적인 assert의 경우에는 메시지가 중요합니다. 메시지는 정확히 무엇이 실패했는지 즉시 이해할 수있는 충분한 컨텍스트를 얻는 데 도움이됩니다.

그러나 필요한 컨텍스트의 양 (따라서 메시지의 세부 정보)은 보고서를받는 방법에 따라 달라집니다. 예를 들어 Eclipse에서 가져 오면 쉽게 가서 상호 작용하고 무슨 일이 일어 났는지 볼 수 있으므로 메시지가 덜 중요합니다. 그러나 보고서를 이메일로 받으면 (예 : 지속적인 빌드 서버에서) 해당 소스 코드로 이동하기 전에 무슨 일이 일어나고 있는지 알 수 있도록 충분한 정보를 메시지에 제공해야합니다.

---

generel의 메시지가 유용한 지 고려하지 않고 질문에 답하고 싶습니다.

테스트가 실패하면 문제가있는 것입니다. 나는이 사실을 알고. 왜 고장 났는지 알고 싶습니다. 테스트 케이스와 SUT를 열기 만하면되므로 쉽게 찾을 수 있습니다. Jon이 말했듯이, 그것을 고치는 것은 매우 쉽습니다 (희망적으로 ;-)).

하지만 메시지는 어떻습니까? 이 메시지는 저에게 조언이며,이를 녹색 테스트 케이스로 바꾸기 위해 무엇을 할 수 있는지에 대한 것입니다. 따라서 메시지 텍스트에 제공된 조언,이 문제를 해결하는 방법 또는 문제를 검색 할 위치가 있으면 감사하겠습니다.

또 다른 흥미로운 측면은 긍정적 인 표현을 사용하는 것입니다. 긍정적 인 문자 메시지를 사용하는 것은 고려할 가치가 있습니다. 귀하의 예에서는 Objects should be identical. 그러나 그것은 작은 이유입니다.

---

저는이 질문을 두 가지 관점에서 봅니다.

첫 번째이자 가장 일반적인 관점은 여기 에서 이미 대부분의 사람들이 논의하고 있습니다. 로그를보고 오류를 수정하려는 사람의 관점에서 : 두 메시지 모두 동일한 정보를 제공한다고 생각합니다.

두 번째 관점은 코드를 읽고 / 유지 / 검토하는 사람의 관점입니다. 우리는 코드 의 가독성과 단순성에 대해 오랫동안 이야기 해 왔습니다. 따라서 그것은 또한 똑같이 중요합니다.

우리는 내 코드가 간단하고 자명해야한다고 믿게되어 명시적인 주석이 필요하지 않으며 이에 강력히 동의합니다.

이 관점에서 :

이러한 메시지는 문서화 및 오류보고의 두 가지 목적을 제공하므로 코드를 훨씬 쉽게 읽고 살펴볼 수 있습니다.

assertEquals( "objects should be identical", expected, actual );
assertTrue( "flag should have been set", flag );
assertNotNull( "object must not be null", object );

이러한 메시지는 예상치 못한 상황에 대해 이야기하기 때문에 독자 친화적이지 않습니다.

assertEquals( "objects aren't identical", expected, actual );
assertTrue( "flag is not set", flag );
assertNotNull( "object is null", object );

---

사양에 따르면 메시지는 오류가 발생했을 때 설명하는 것입니다. Jenkins와 같은 CI 환경에서 애플리케이션을 빌드하고 플러그인을 사용하여 오류 결과를 분석 할 때 유용합니다.

http://junit.sourceforge.net/javadoc/org/junit/Assert.html#assertTrue(java.lang.String,%20boolean)

message-AssertionError에 대한 식별 메시지 (null 괜찮음)

---

저도 투표 해주세요 (예 : Jon),하지만 이와 같은 메시지를 사용한 유일한 시간은 값 행렬이있는 단일 테스트를 빌드하고 테스트 요소 중 하나가 실패 할 때입니다. 메시지를 사용합니다. 실패한 테스트 케이스를 나타냅니다. 그렇지 않으면 텍스트가 완전히 중복됩니다.

---

JUnit의 javadocs에서 :

Asserts that two objects are equal. If they are not an AssertionFailedError is thrown with the given message.

According to the API, the message can be whatever you want. I would argue that the two options you have are both the same and both superfluous. The success or failure of the assert already provides all the information you are providing in the message.

It follows for me that you should have either nothing (there is an assert that doesn't take a string on purpose) OR include a message with meaning beyond what is already there.

So I guess this is a reiteration of Jon's answer, but too verbose to be a comment.

---

I don't put a message for the case you cite, unless I'm running a test where I have an array of similar test values that I'm running in a loop and I want to pinpoint exactly which one failed. Then I add a message to tell me which one.

---

I agree that providing a message is helpful and I always provide one.

To me, the useful thing to include is a clear statement of what went wrong - usually involving the words 'should' or 'should not'.

E.g., "objects are equal" is ambiguous - does it mean the objects are equal and that's why the test failed? Or that objects should be equal but they aren't? But if you say "Objects should be equal" or "Objects should not be equal" it's obvious why the assertion failed.

---

I particularly like how the Spock test framework encourages tests that read like a story and have come to structure tests under different frameworks similarly. I'm not particularly concerned about the individual error message making a lot of sense, I aim for quickly wrapping my head around the entire test once I open it:

assertEquals("Cloned and persisted items", mockedTiCount, clonedTis.size());
assertTrue("Belong to new transaction", clonedTis.stream().allMatch(ti -> ti.getTransaction().getId().equals(cloned.getId())));
assertNotEquals("Which has a different ID", t.getId(), cloned.getId());
assertEquals("While the originals are left intact", mockedTiCount, transactionItemRepository.findByTransactionId(t.getId()).size());

Opting for many small tests instead of few large ones helps here as well, as does a neatly structured, hopefully reusable, test setup code.

참고URL : https://stackoverflow.com/questions/1074928/should-the-junit-message-state-the-condition-of-success-or-failure