그 대화에 대한 나의 해석은 다음과 같습니다.
- 클래스가 아닌 테스트 구성 요소
- 인터페이스 포트를 통해 구성 요소를 테스트하십시오.
대화에서 언급되지는 않았지만 조언에 대한 가정 된 내용은 다음과 같습니다.
- 유틸리티 라이브러리 나 프레임 워크가 아닌 사용자를위한 시스템을 개발하고 있습니다.
- 테스트의 목표 는 경쟁력있는 예산 내에서 가능한 한 많은 것을 성공적으로 제공하는 것입니다.
- 구성 요소는 C # / Java와 같이 성숙하고 정적 인 유형의 단일 언어로 작성됩니다.
- 컴포넌트는 10000-50000 라인 정도이다. Maven 또는 VS 프로젝트, OSGI 플러그인 등
- 구성 요소는 단일 개발자 또는 밀접하게 통합 된 팀이 작성합니다.
- 육각형 아키텍처 와 같은 용어와 접근 방식을 따르고 있습니다.
- 컴포넌트 포트는 http / SQL / XML / bytes / ...로 전환하여 로컬 언어 및 해당 유형 시스템을 떠나는 곳입니다.
- 모든 포트를 랩핑하는 것은 Java / C #의 의미로 유형이 지정된 인터페이스로, 스위치 기술로 구현을 전환 할 수 있습니다.
따라서 구성 요소 테스트는 단위 테스트라고 할 수있는 가장 큰 범위입니다. 이것은 일부 사람들, 특히 학계에서이 용어를 사용하는 방법과는 다릅니다. 일반적인 단위 테스트 도구 자습서의 예제와 다릅니다. 그러나 하드웨어 테스트에서 그 기원과 일치합니다. 보드 및 모듈은 와이어 및 나사가 아닌 장치 테스트를 거쳤습니다. 또는 적어도 나사를 테스트하기 위해 모의 보잉을 만들지 마십시오 ...
그것으로부터 외삽하고 내 자신의 생각을 던져
- 모든 인터페이스는 입력, 출력 또는 공동 작업자 (예 : 데이터베이스)가됩니다.
- 입력 인터페이스 를 테스트 합니다. 메소드를 호출하고 리턴 값을 지정하십시오.
- 출력 인터페이스 를 조롱 합니다. 주어진 테스트 케이스에 대해 예상되는 메소드가 호출되었는지 확인하십시오.
- 공동 작업자 를 위조 합니다. 간단하지만 작동하는 구현을 제공하십시오
적절하고 깨끗하게하면 조롱 도구는 거의 필요하지 않습니다. 시스템 당 몇 번만 사용됩니다.
데이터베이스는 일반적으로 공동 작업자이므로 조롱하기보다는 위조됩니다. 손으로 구현하는 것은 고통 스러울 것입니다. 운 좋게도 그런 것들이 이미 존재합니다 .
기본 테스트 패턴은 일련의 작업을 수행하는 것입니다 (예 : 문서 저장 및 다시로드). 작동하는지 확인하십시오. 이것은 다른 테스트 시나리오와 동일합니다. (작동) 구현 변경으로 인해 그러한 테스트가 실패 할 가능성이 없습니다.
테스트중인 시스템에서 데이터베이스 레코드를 쓰지만 읽지 않는 경우는 예외입니다. 예 : 감사 로그 또는 유사 이것들은 출력이므로 조롱해야합니다. 테스트 패턴은 일련의 작업을 수행하는 것입니다. 지정된대로 메소드와 인수로 감사 인터페이스가 호출되었는지 확인하십시오.
여기에서도 mockito 와 같은 유형 안전 모의 도구를 사용하는 경우 인터페이스 메소드의 이름을 바꾸면 테스트 실패가 발생할 수 없습니다. 테스트가로드 된 IDE를 사용하는 경우 메소드 이름 바꾸기와 함께 리팩터링됩니다. 그렇지 않으면 테스트가 컴파일되지 않습니다.