자체 테스트 코드와 분리 테스트의 장점은 무엇입니까?

Question

개인적으로 필자는 MSTest가 설정된 것처럼 보이기 때문에 개인적으로 단위 테스트를 별도의 프로젝트에 넣었습니다. 그러나 저는 을 리팩토링하고 있습니다 : 기존 코드의 설계를 마틴 파울러 (Martin Fowler)가 개선 한 것입니다. 그는 동일한 프로젝트에 투입하는 것뿐만 아니라 테스트중인 메소드와 동일한 클래스에 넣는 것을지지하는 것으로 보입니다.

철저한 차이 (테스트 문서 또는 혼란이 아닌) 이외의 코드 자체와 다른 영역에서 테스트하는 것과 다른 점을 생각해 보니 정말 솔직하게 문제가 있습니다.

다른 하나를 선택해야하는 명확한 이유가 있습니까? 아니면 이것은 주로 철학적 차이입니까?

업데이트 : 나는 아직 어떤 방법으로 확신 할 수는 없지만 적어도 논쟁이 무엇인지 생각해 봅니다. 나는 모든 사람의 대답을 선택할 수 있었으면 좋겠다. 그러나 나는 하나만 선택해야했다.

Answer 1

아마도 자체 테스트 코드를 사용하는 것의 우아함이 있습니다. 그러나 필자는 당신과 똑같은 철학을 가지고있는 경향이 있습니다. 코드 분리는 추상적 인 아름다움의 개념보다 우선합니다. 당신이 클래스를 디자인 할 때, 당신은 기본적으로 세 부분으로 나눌 수 :

• 클래스는 무엇을 (예를 들어, 클래스의 정의) 그것을 수행하는 방법
• (구현) 사용 방법
• (문서 및/또는 테스트 케이스)

테스트 사례가 문서의 목적과 테스트 세트의 안전망의 일부로 간주됩니다. 새로운 프로그래머가 코드를보고있을 때, 아마도 작업을 중단 한 후에 오랜 시간이 지나면 문서가 클래스 사용 방법을 알려주는 가장 효과적인 방법은 거의 없습니다. 특정 상황에서 코드가 어떻게 작동하는지에 대한 질문에 대답하고 클래스에 대한 전반적인 개요와 메서드 등을 제공 할 수 있지만 테스트 사례에서는 클래스가 실제 코드에 사용되는 방법에 대한 구체적인 예를 제공합니다.

그렇기 때문에 나는이 정도의 분리를 다시 시행하기 때문에 클래스 자체 외부에 있어야한다고 말하고 싶습니다.

Answer 2

그것은 주로 생각하는 철학적 차이입니다.

별도의 프로젝트에서 테스트를 수행 할 때 성능상의 이점은 있지만 (테스트가 프로덕션에 배치되지 않은 경우) 인 것은 아마도이 아닙니다.

또한 리팩토링은 꽤 오래 전 (IT 용어로) 작성되어 선호하는 관행이 그때 이후로 전환되었을 수도 있음을 기억하십시오.

Answer 3

NUnit은 기본 매개 변수없는 생성자가없는 유형을 테스트하지 않으므로 테스트 할 때 같은 클래스에 넣으면 인기있는 단위 테스트 프레임 워크가 손상 될 수 있습니다.

동일한 프로젝트이지만 다른 프로젝트에 테스트를 적용하는 것이 더 좋지만 기본 프로젝트에서 NUnit.Framework.dll과 같은 테스트 프레임 워크는 물론 Rhino.Mocks.dll과 같은 조롱 프레임 워크를 참조하게됩니다.

테스트중인 클래스 내부에서 테스트를하면 분산 프로젝트의 크기가 커집니다.

테스트를 별도의 프로젝트로 분리하면 이러한 문제가 발생하지 않습니다.

Answer 4

당신이 원하는 것 무엇 일반적으로 단지 생산 코드를 배포 할 수있는 옵션을 유지하는 좋은 방법입니다 (무엇이든, 하위 디렉토리, 프로젝트) 별도의 지역에서 테스트를 유지.

Answer 5

테스트중인 동일한 클래스에서 테스트하는 데 많은 편의가 있습니다. 꽤 자주 (그리고 TDD에 착수하기 전에) 필자는 필자가 작성한 코드의 기능을 테스트하기 위해 Main 메소드를 클래스에 추가했다. 테스트 코드가 거짓말을하는 것이 매우 유용했기 때문에 main 메서드를 제거하지 않았습니다. 같은 의미에서 문서에 코드를 묶는 것이 편리하다는 점에서 편리합니다. 필자는 테스트 코드를 어디서 검색 할 필요가 없었습니다.

TDD의 요점은 테스트/품질 보증에 관한 것만은 아닙니다. 디자인/인터페이스에 대해 생각해 보는 것이 중요합니다. 그리고 그 관점에서 "테스트"(a.k.a "디자인") 코드를 별도의 파일에 포함하는 것이 좋습니다. "테스트"코드는 클래스의 클라이언트/사용자입니다.

테스트를 별도의 파일로 작성하려는 목적이 기술적 인 경우 (예 : "단위 테스트 프레임 워크가 그렇게 설계 되었기 때문에"또는 "기본 프로젝트에 참조를 포함해야 할 경우"또는 " 그것은 성능을 향상시킵니다 "라고 말하면서 매우 설득력있게 들립니다. 그것이 사실이라면 상황은 매우 다르게 진행되었을 것입니다.

Answer 6

테스트 코드와 프로덕션 코드가 동일한 클래스에있는 데 따른 이점이 없습니다. 대신에 나는 몇 가지 단점을 참조하십시오

• 배포하고 테스트 코드없이 생산 코드를 배포 할 수 없습니다. 따라서 100KB 파일 대신 200KB 이상의 파일을 제공해야 할 수도 있습니다. (TDD를 사용하는 경우 테스트 코드 줄은 종종 생산 코드 줄과 동일하거나 더 큽니다.)

• 테스트 구조가 프로덕션 코드와 너무 밀접하게 연결되어 있습니다. 테스트와 프로덕션 클래스 간에는 1 : 1 관계가 없어야합니다. 대신, 테스트와 행동 사이에 1 : 1 관계가 있어야합니다.

는 http://blog.daveastels.com/files/BDD_Intro.pdf

에서 인용 "당신은 모든 테스트를 작성보기 이동의 요점을 동작을 지정하지 관하여 실현합니다. 생산의 각 테스트 클래스를 갖는 갑자기 생각을 수업은 엄청나게 제한적이며, 각 방법을 자체 테스트 방법 (1-1 관계)으로 테스트하려는 생각은 우스꽝 스럽습니다. "

주로 Java로 프로그램하고 Maven을 사용하여 프로젝트를 만듭니다. 테스트 할 대상은 같은 모듈과 패키지이지만 다른 디렉토리 (/ src/main/java 및/src/test/java)에 있습니다. 메이븐은 프로젝트를 빌드 할 때 모든 테스트를 실행하지만, 프로덕션 코드 만이 배포 가능한 바이너리에 포함됩니다.