우리 모두는 단위 테스트와 통합 테스트를 작성해야한다는 것을 알고 있지만 때로는 그 이유가 명확하지 않습니다. 너무 자주 우리는 둘 사이의 관심사 분리가 명확하게 정의되지 않은 프로젝트를 찾습니다. 일부 범위는 둘 이상의 테스트에서 다루고 다른 범위는 제대로 다루지 않습니다.

예

사용자가 악한 방식으로 세상을 장악 할 수 있는 다음 응용 프로그램 을 고려해 보겠습니다 .

미디어를 장악하고 사악한 기술 개발을 가속화하는 스레드를 실행하고 마침내 디스토피아적인 미래를 설치합니다.

세계가 지배적으로 보일 것입니다.

단위 테스트를 사용하여이 동작을 테스트해야합니다. 단위 테스트는 각 구성 요소를 자체적으로 테스트해야합니다. 해당 구성 요소 만 테스트하고 종속성이 없는지 확인하기 위해 모의를 사용합니다.

예를 들어, 다음은 서비스 테스트입니다.

다음은 컨트롤러 용입니다.

아시다시피 통합 테스트는 서로 다른 구성 요소가 서로 어떻게 작동하는지 테스트해야하며 여기에는 Spring 컨텍스트가 포함됩니다. 블랙 박스를 유지하고 싶기 때문에 컨트롤러를 호출하고 결과가 예상대로인지 확인해야합니다 (세계가 지배적입니다) .

이제 우리가 세계 지배 퀘스트에서 그렇게 악하지 않기로 결정하면 어떨까요? 우리가 무료 미디어를 허용하고 놀라운 좋은 기술과 밝은 미래를 가지기로 결정하면 어떨까요?

즉, 다른 구현 을 선택하기로 결정하면 어떻게됩니까?

이제 단위 테스트를 사용하여 테스트해야하는 새로운 기능을 추가했습니다.

그러나 기본 구현을 변경하여 여전히 원하는 결과를 얻고 있음을 어떻게 알 수 있습니까? 단위 테스트가 변경되었지만 통합 테스트는 다음과 같이 변경 되지 않았습니다.

지금해야 할 일은 다시 실행하기 만하면됩니다. 애플리케이션이 정상적으로 작동한다는 것을 알고 있습니다.

요점

잘 설계된 통합 테스트를 통해 테스트중인 범위의 기본 구현을 변경해도 원하는 결과가 변경되지 않는다고 쉽게 주장 할 수 있어야합니다.

통합 테스트는 애플리케이션 컨텍스트를로드하고 모의를 사용하지 않는 단위 테스트가 아니어야합니다. 그 범위는 더 커야하며, 정의에 따라 특정 기능을 달성하기 위해 함께 작동하는 여러 계층을 포함해야합니다. 이것이 바로 우리가 주로 블랙 박스로 수행하는 이유입니다. 여기서는 컨트롤러의 응답이나 데이터베이스 상태와 같이 외부에서 애플리케이션을 살펴보고 단위 테스트 (예 : 스파이 빈 및 확인)에서와 같이 구성 요소 간의 상호 작용이 아닌 전화).

프로젝트 구조에 대한 한마디

단위 테스트는 기본 폴더의 모든 구성 요소를 포함해야하므로 테스트 폴더의 구조는 다음을 반영해야합니다.

하지만 통합 테스트는 어떻습니까? 어디에 적합합니까? 이를 처리하는 한 가지 방법은 별도의 소스 디렉토리에 두는 것입니다.

이것은 maven에서 쉽게 구성 할 수 있습니다.

Maven은 기본적으로 단위 테스트와 통합 테스트를 이런 방식으로 구분하지만, 이름을 다르게 지정하는 것으로도 충분합니다 (각각 * Test 및 * IT, 여기서도 수행합니다). 다른 디렉토리는 단순히 조직 측면에서 우리를 더 돕습니다.

도움이 되었기를 바랍니다 :)

여기 에서 프로젝트를 확인 하세요