주니트 테스트는 Javadocced해야합니까?

Question

현재 Javadoc 의견으로 문서화되지 않은 주니트 테스트 사례가 여러 개 있습니다.

내 코드의 나머지 부분은 문서화되어 있지만 이러한 테스트를 문서화하려는 노력도 할 가치가 있는지 궁금합니다.

Answer 1

테스트의 목적이 명백하다면, 나는 그것을 문서화하는 것을 귀찮게하지 않습니다.

모호한 상황을 다루거나 특정 버그를 참조하려는 경우 (예 : 저것 사례 문서를 추가하겠습니다. 그래도 예외 던지기 등을 문서화하지 않습니다. 이것은 비교적 드물게 발생합니다. 여러 테스트에서 사용되는 도우미 방법에 대한 문서를 추가 할 가능성이 높습니다.

Answer 2

테스트 사례를 Javadocing에서는 아무런 가치도 없습니다. 나는 단지 테스트의 목적을 알기에 충분히 설명 이름을 설명합니다.

루비에서는 테스트 이름에서 문서를 만들 수있는 도구가 있다는 것을 알고 있지만 Java에서는이 중 하나를 보지 못했습니다.

Answer 3

Javadoc이든 아니든, 단위 테스트는 반드시 문서화되어야한다고 생각합니다. 공식 사양이없는 경우, 단위 테스트는 코드의 예상 동작을 정의하는 데 가장 가까운 것입니다. 테스트 사례를 문서화하면 독자에게 테스트가 무엇인지, 테스트하는 이유를 명확하게 할 수 있습니다.

Answer 4

테스트를 문서로 생각할 때 "문서를 문서화"하는 것은 의미가 없습니다. 각 테스트의 이름은 이미 테스트의 목적이 무엇인지 - 해당 테스트에 의해 지정되는 행동이 무엇인지 설명해야합니다.

테스트의 긴 설명 이름을 사용하고 시험 코드를 최대한 읽을 수 있도록 유지하십시오.

예를 들어 테스트 사례를 살펴보십시오 이 프로젝트에서. 그들 중 누구도 테스트의 이름과 테스트 코드를 보면서 명백하게 명백하지 않은 일을합니까?

테스트 코드가 모호한 경우에는 드문 경우에만 테스트에서 의견이 필요합니다. 예를 들어, 멀티 스레드 코드를 테스트하는 경우 테스트 코드가 올바른 순서로 실행되도록 테스트 코드가 이상한 작업을 수행합니다. 그러나 그 경우에도 의견은 사과입니다 클리너 테스트 코드를 작성하지 않기 위해.

Answer 5

의견과 관련하여 프로덕션 코드와 다른 테스트 케이스를 처리 해야하는 이유를 모르겠습니다.

Answer 6

테스트가 통과하는 조건을 Javadoc에게는 가치가 있다고 생각합니다.

Answer 7

코드 댓글이 패턴이라는 것을 제안하는 것이 유대 한가? 위의 답변에 동의합니다. 이상적으로 귀하의 코드는 의견없이 의존 할만 큼 설명 할 수 있습니다. 사람들이 댓글을 업데이트하지 않고 코드를 업데이트하는 경향이있는 (엔터프라이즈) 환경에있는 경우 특히 그렇습니다. 따라서 의견이 오도됩니다.

Answer 8

지옥 그래. 그냥 ...

주문, 주문 편집, 저장,로드 및 확인하십시오.

정말 간단한 테스트라면 아마도 그렇지 않을 수도 있습니다.

코드가 변경됨에 따라 때로는 테스트의 이유가 예전처럼 분명하지 않습니다.

Answer 9

어쩌면 코드에 익숙하지 않은 사람이 테스트를 쉽게 이해하는지 여부에 대한 빠른 피드백을 제공 할 수 있습니다.

내가 일하는 회사에서는 테스트 설명 이름과 복잡성을 문서화하려고 노력하지만 개발자에게 명백한 것이 항상 다른 사람들에게 분명하지는 않기 때문에 첫 번째 초안 으로이 "올바른"을 얻는 것은 종종 어렵습니다.

테스트는 코드처럼 취급되며 동료 검토 프로세스의 일부로 제출되므로 (작은) 팀은 테스트가 쉽게 이해되는지 여부에 대해 의견을 제시 할 수 있습니다.

테스트가 약간 혼란 스러우면 그에 따라 이름이나 문서를 업데이트 할 수 있으며 작동하는 것과 그렇지 않은 것의 더 나은 게이지가 나옵니다.