여기서 살펴 봐야 할 두 가지 문제가 있습니다.
첫 번째는 단위 테스트 관점에서 모든 테스트를보고있는 것 같습니다. 단위 테스트는 매우 중요하지만 유일한 테스트는 아닙니다. 테스트는 실제로 매우 빠른 단위 테스트 에서 덜 빠른 통합 테스트 , 더 느린 수락 테스트에 이르기까지 여러 계층으로 나눌 수 있습니다 . ( 기능 테스트 와 같이 더 많은 레이어가 나올 수 있습니다 .)
두 번째는 비즈니스 로직과 타사 코드 호출을 혼합하여 테스트 문제를 일으키고 코드를 더 취약하게 만드는 것입니다.
단위 테스트는 빠르며 자주 실행해야합니다. 종속성을 모의하면 이러한 테스트를 빠르게 실행하는 데 도움이되지만 종속성이 변경되고 모의가 변경되지 않으면 적용 범위에 문제가 발생할 수 있습니다. 테스트가 여전히 녹색으로 실행되는 동안 코드가 손상 될 수 있습니다. 일부 조롱 라이브러리는 종속성의 인터페이스가 변경되면 경고하지만 다른 라이브러리는 그렇지 않습니다.
반면에 통합 테스트는 타사 라이브러리를 포함하여 구성 요소 간의 상호 작용을 테스트하도록 설계되었습니다. 실제 객체가 상호 작용하는 방식을보고 싶기 때문에이 수준의 테스트에서는 Mocks를 사용해서는 안됩니다. 실제 객체를 사용하기 때문에 이러한 테스트 속도가 느려지고 단위 테스트만큼 자주 실행하지는 않습니다.
승인 테스트는 소프트웨어의 요구 사항이 충족되는지 테스트하면서 훨씬 더 높은 수준을 확인합니다. 이러한 테스트는 배포 될 전체 시스템 전체에 대해 실행됩니다. 다시 한 번 조롱을 사용해서는 안됩니다.
사람들이 모의와 관련하여 귀중한 것으로 알고있는 지침 중 하나는 소유하지 않은 유형을 조롱하는 것 입니다. Amazon은 S3에 대한 API를 소유하므로 그 아래에서 변경되지 않도록 할 수 있습니다. 반면에, 당신은 이러한 확신을 가지고 있지 않습니다. 따라서 테스트에서 S3 API를 모의하면 코드가 변경되고 중단 될 수 있지만 테스트는 모두 녹색으로 표시됩니다. 그렇다면 타사 라이브러리를 사용하는 코드를 어떻게 단위 테스트합니까?
글쎄, 우리는하지 않습니다. 지침을 준수하면 소유하지 않은 물건을 조롱 할 수 없습니다. 그러나 ... 직접 의존성을 소유하고 있다면 그것을 조롱 할 수 있습니다. 그러나 어떻게? 우리는 S3 API를위한 자체 래퍼를 만듭니다. S3 API와 비슷하게 보이게하거나 필요에 더 잘 맞도록 (바람직하게) 만들 수 있습니다. 우리는 심지어 조금 더 추상적하는 말을 할 수 PersistenceService보다는를 AmazonS3Bucket. and와 PersistenceService같은 메소드가있는 인터페이스 가 될 것입니다. 이제 호출 코드에서 캡슐화 하여 S3 API 주변 (예 :)을 구현할 수 있습니다 .#save(Thing)#fetch(ThingId)PersistenceServiceS3PersistenceService
이제 S3 API를 호출하는 코드입니다. 이러한 호출을 PersistenceService객체 에 대한 호출로 교체해야 합니다. 의존성 주입 을 사용 PersistenceService하여 객체 에 전달 합니다. 을 요구 하지 말고을 요청하는 것이 중요 S3PersistenceService합니다 PersistenceService. 이를 통해 테스트 중에 구현을 교체 할 수 있습니다.
S3 API를 사용하는 데 사용하는 모든 코드는 바로 지금 우리를 사용하여 PersistenceService, 우리는 S3PersistenceService이제 S3 API에 대한 모든 호출합니다. 테스트에서 우리는 PersistenceService그것을 소유하고 있기 때문에 mock out 할 수 있고 mock을 사용하여 코드가 올바르게 호출되는지 확인할 수 있습니다. 그러나 이제는 테스트하는 방법이 남습니다 S3PersistenceService. 이전과 같은 문제가 있습니다. 외부 서비스를 호출하지 않으면 단위 테스트를 수행 할 수 없습니다. 우리는 그것을 단위 테스트하지 않습니다. 우리 는 S3 API 의존성을 모방 할 수 있지만, 그에 대한 확신은 거의 없습니다. 대신, 우리는 통합 테스트라는 높은 수준에서 테스트해야합니다.
코드의 일부를 단위 테스트하지 말고 우리가 달성 한 것을 살펴 보자. 우리는 단위 테스트를 할 수 없었던 곳곳에 많은 코드가 있었는데, 이제는를 통해 단위 테스트를 할 수 있습니다 PersistenceService. 우리는 타사 라이브러리 엉망이 단일 구현 클래스에 국한되어 있습니다. 해당 클래스는 API를 사용하는 데 필요한 기능을 제공해야하지만 외부 비즈니스 로직이 첨부되어 있지 않습니다. 따라서 일단 작성되면 매우 안정적이어야하며 크게 바뀌지 않아야합니다. 코드가 안정적이기 때문에 자주 실행하지 않는 느린 테스트에 의존 할 수 있습니다.
다음 단계는에 대한 통합 테스트를 작성하는 것입니다 S3PersistenceService. 빠른 단위 테스트와 별도로 실행할 수 있도록 이름 또는 폴더로 분리해야합니다. 통합 테스트는 코드가 충분한 정보를 제공하는 경우 단위 테스트와 동일한 테스트 프레임 워크를 사용할 수 있으므로 새로운 도구를 배울 필요가 없습니다. 통합 테스트에 대한 실제 코드는 옵션 1에 대해 작성하는 것입니다.