단위 테스트는 실제로 문서로 사용됩니까?

나는 '단위 테스트는 테스트 대상 코드를 문서화하는 매우 중요한 소스'라는 맥락에서 문장을 읽는 횟수를 셀 수 없습니다. 나는 그들이 진실임을 부정하지 않습니다.

그러나 개인적으로 나는 그것들을 문서로 사용하는 것을 찾지 못했습니다. 내가 사용하는 일반적인 프레임 워크의 경우 메소드 선언에 동작이 문서화되어 있으며 이것이 전부입니다. 그리고 단위 테스트는 해당 문서에 명시된 모든 내용과 더 많은 내부 내용을 백업한다고 가정하므로 한쪽은 ducumentation을 복제하고 다른 쪽은 관련성이없는 부분을 추가 할 수 있습니다.

문제는 언제 단위 테스트가 문서화로 사용됩니까? 주석이 모든 것을 다루지 않는 경우? 개발자가 소스를 확장함으로써? 문서 자체가 노출 할 수없는 유용하고 관련성이있는 것은 무엇입니까?

그들은 절대 참조 문서가 아닙니다

테스트와 같이 코드와 동기화되지 않을 수 있으므로 주석에는 다음 사항이 많이 적용됩니다.

결국 코드를 이해하는 가장 좋은 방법은 작업 코드를 읽을 수있게하는 것입니다 .

^{하드 배선 된 저수준 코드 섹션 또는 특히 까다로운 조건을 전혀 작성하지 않으면 추가 문서가 중요합니다.}

• 테스트가 불완전 할 수 있습니다.
  • API가 변경되었고 테스트되지 않았습니다.
  • 코드를 작성한 사람은 테스트 할 가장 중요한 방법 대신 테스트하기 가장 쉬운 방법에 대한 테스트를 작성했지만 완료 할 시간이 없었습니다.
• 테스트는 더 이상 사용되지 않을 수 있습니다.
• 테스트는 명백하지 않은 방식으로 단락 될 수 있으며 실제로 실행되지는 않습니다.

그러나 여전히 유용한 문서 보완 물입니다.

그러나 특정 클래스의 기능에 대해 의문이있는 경우, 특히 길고 모호하고 주석이 부족한 경우 (당신은 종류를 알고 있습니다 ...), 테스트 클래스를 찾아서 확인하려고합니다.

• 그들이 실제로 확인하려고하는 것
• 코너 케이스가있는 경우.

경우 플러스, BDD 스타일을 사용하여 작성 , 그들은 클래스의 계약 오히려 좋은 정의를 제공합니다 . 메소드 이름과 tada 만 보려면 IDE를 열거 나 grep을 사용하십시오. 동작 목록이 있습니다.

회귀 및 버그에는 테스트가 필요함

또한 회귀 및 버그 보고서에 대한 테스트를 작성하는 것이 좋습니다. 문제를 해결하고 사례를 재현하기위한 테스트를 작성합니다. 예를 들어 관련 버그 보고서와 이전 문제에 대한 모든 세부 정보를 찾는 것이 좋습니다.

나는 이것이 실제 문서에 대한 좋은 보완이며 적어도 이와 관련하여 귀중한 자원이라고 말하고 싶습니다. 올바르게 사용하면 좋은 도구입니다. 프로젝트 초기에 테스트를 시작하고 습관을 들이게되면 매우 훌륭한 참고 문서가 될 수 있습니다. 코딩 습관이 나쁜 기존 프로젝트에서 이미 코드 기반을 스텐트 처리하는 경우주의해서 처리하십시오.

한 가지 해석은 단위 테스트가 "실행 가능한 문서"라는 것입니다. 코드에 대해 단위 테스트를 실행할 수 있으며 테스트를 통과했을 때와 같이 여전히 수행 중인지 여부를 알려줍니다. 이러한 방식으로 장치는 실행 가능한 방식으로 특정 시점에 시스템 기능을 "문서화"합니다.

반면에 나는 기능 테스트를 위해 단위 테스트 코드를 "문서"라고 거의 읽지 않았다. 단일 단위 테스트는 테스트 대상 클래스 뒤에있는 실제 시스템에 대해 많은 정보를 제공 할 수 있도록 너무 현지화되고 구체적이며 추상적입니다.

문서에 따르면 코드가 어떻게 작동하는지 알아 내고 싶다면 단위 테스트는 코드 단위가 예상 , 엣지 케이스 및 실수 (일명 버그 ) 케이스 에서 어떻게 작동하는지에 대한 완벽한 작은 예입니다 . 또한 코드를 작성하기 전에 테스트를 작성하여 비즈니스 / 요구 사항 관점에서 코드가 수행해야 할 작업의 기초가됩니다.

문서를 대체하고 있습니까? 아니.

그것들은 문서에 대한 유용한 부록입니까? 예.

단위 테스트는 다음과 같습니다.

• 문서가 올바른지 증명하는 방법 (문서가 api 구현과 일치한다고 가정).
• 특정 기능을 사용하는 방법을 개발자에게 시연하는 방법; 단위 테스트 픽스처 / 단위 테스트 자체는 일반적으로 빠르게 배울 수있을 정도로 작습니다.
• 분명히 회귀 버그를 발견했습니다.

어느 정도 확장하면 기존 문서를 보완하는 것으로 볼 수 있지만 문서는 아닙니다.

다른 질문을함으로써 귀하의 질문에 대답하겠습니다.

새로운 API / 루틴으로 작업 할 때 사용하려는 코드 예제를 찾기 위해 얼마나 자주 도움을 얻었습니까? 코드 샘플을 온라인으로 검색하기 위해 Google로 전환하지 못하는가?

바로 단위 테스트를 문서로 사용할 때입니다.

• 실제로 여러 테스트 (예)가 있어야 하기 때문에 단위 테스트는 일반 코드 예제보다 조금 더 엄격 할 수 있습니다 .
• 단위 테스트가 올바른 사용법을 보여주기를 바랍니다 . 예를 들어 일반 객체 또는 모의 객체를 통해 모든 필수 종속성을 명확하게 보여줍니다. (그렇지 않으면 단위 테스트가 특히 좋지 않습니다.)
• 참고 : 의견 또는 "일반 문서"가 코드 예제를 제공하는 경우 실제로 DRY 원칙을 위반하는 것입니다. 그리고 이러한 코드 예제는 시간 이 지남에 따라 쉽게 부정확 해질 수 있지만 정기적으로 실행되는 단위 테스트의 가능성은 크게 줄어 듭니다.
• 단위 테스트가 철저한 경우 (보통 큰 경우 ) 추가 정보를 제공해야합니다.
  • 알려진 모든 에지 사례가 명확하게 설명되어 있습니다.
  • 발생 가능한 모든 예외.
  • 이전에 발견 된 모든 버그 (이것은 장치의 새 클라이언트를 작성할 때보 다 테스트중인 장치를 확장 할 때 더 유용 할 것입니다).
  • 장치와 관련된 모든 기본 비즈니스 규칙. (만약에 어떠한)

단위 테스트가 더 전통적인 문서를 보완 할 수는 있지만 문서로 사용되지 않는 데는 몇 가지 이유가 있다고 생각 합니다.

• 나는 종종 테스트 자체가 목적을 위해 충분히 작성되지 않았다고 제안하려고 노력했다. 다른 답변은 이미 다음과 같은 테스트를 암시했습니다.
  • 불완전한.
  • 혼란스러운. (테스트중인 메소드를 직접 호출하지 않는 테스트 사례를 보았습니다. 호출 스택이 호출되기 전에 3/4 레벨 깊숙이 들어가고 메소드를 호출하기위한 전제 조건이 복잡한 클래스 계층의 다른 위치에 흩어져 있습니다. )
  • 구식. 일반적으로 테스트 가 오래되면 실패 해야 하지만 항상 그런 것은 아닙니다.
• 예제가 필요할 때마다 프로덕션 코드에서 이미 사용 가능한 예제가 많이 있습니다.
• 테스트중인 단위는 너무 잘 작성되어 있으므로 (자체 문서화) 메소드에 예제가 필요하지 않습니다. 나는 원한다!
• 프로그래머로서의 경험에서 우리는 다음주 화요일 심야와 RTFM에 뛰어 들려고하는 경향이 있습니다 ...
• DRY 원칙을 위반하는 문서 및 의견.

TL; DR 단위 테스트 및 API 주석은 상호 보완 적입니다. 일부는 코드에서 가장 잘 설명되고 일부는 산문으로 설명됩니다.

단위 테스트는 주로 API 주석에 설명하기 어려운 특수한 상황과 엣지 조건을 문서화하는 데 유용합니다. 또한 API 주석은 일반적으로 API를 사용하려는 사람들에게 전달됩니다.

코드를 수정하려면 일반적으로 알아야 할 것이 훨씬 더 많으며 일부는 주석으로 작성하기가 어렵습니다 (이러한 주석은 빨리 지체됩니다). 이 경우 단위 테스트는 문서로도 작동합니다.

예 : (a, b)특정 계산을 수행하는 방법 m 이 있습니다. 이전 버전과의 호환성 요구 사항으로 인해 a=0및의 특수한 경우 a=-1에만 입력해야 하지만 bNULL 인 경우에만 가능 합니다. 이를 주석에 넣는 것은 복잡하고 장황하며 나중에 요구 사항이 제거되면 부실해질 수 있습니다.

당신은 몇 가지 단위 테스트를 할 경우 검사의 행동은 m(0, NULL), m(-1, x)당신은 몇 가지 이점을 얻을 :

• 올바른 행동에 대한 설명이 명확하고 오해가 줄어 듭니다.
• 사람들은 주석과 달리 코드를 변경할 때 요구 사항을 간과 할 수 없습니다