필자는 개발중인 API 클라이언트 라이브러리를 단위 테스트하는 가장 좋은 방법을 찾으려고 노력했습니다. 라이브러리에는 Client기본적으로 API와의 1 : 1 매핑이있는 Wrapper클래스 와 의 맨 위에보다 사용자에게 친숙한 인터페이스를 제공 하는 추가 클래스가 Client있습니다.
Wrapper --> Client --> External API
내가 먼저 모두에 대해 테스트의 무리를 작성 Client하고 Wrapper효과적으로 단지 그들이 앞으로가에서 작동 어떤의 적절한 기능 (즉, 그 테스트 Wrapper에 대한 운영 Client및 ClientHTTP를 연결에서 작동). 그러나 인터페이스가 아닌 이러한 클래스의 구현을 테스트하고 있다고 느끼기 때문에 이것에 불편 함을 느끼기 시작했습니다. 이론적으로 클래스를 변경하여 완벽하게 유효한 다른 구현을 할 수는 있지만 호출 될 것으로 예상되는 함수가 호출되지 않아 테스트가 실패합니다. 그것은 나에게 연약한 시험처럼 들린다.
그 후, 나는 수업의 인터페이스에 대해 생각했습니다. 테스트는 클래스가 실제로 수행하는 방식이 아니라 수행하려는 작업을 실제로 수행하는지 확인해야합니다. 어떻게해야합니까? 가장 먼저 떠오르는 것은 외부 API 요청을 스텁하는 것입니다. 그러나 외부 서비스를 지나치게 단순화하는 것에 신경이 쓰입니다. 내가 본 스텁 API의 많은 예제는 미리 준비된 응답을 제공합니다. 이는 가짜 API에 대해 코드가 올바르게 실행되는지 테스트하는 정말 쉬운 방법 인 것 같습니다. 대안은 서비스를 조롱하는 것인데, 이는 실현 불가능하며 실제 서비스가 변경 될 때마다 최신 상태를 유지해야합니다.
마지막으로 프로그래머 SE에 대한 다른 답변에서 이것을 읽었습니다 .
원격 API 클라이언트의 임무는 특정 호출을 발행하는 것입니다. 따라서 테스트를 통해 해당 호출을 발행하는지 확인해야합니다.
그리고 지금 나는 다소 확신합니다-테스트 할 때 테스트 Client해야 할 것은 API에 올바른 요청을한다는 것입니다 (물론 API가 변경 될 가능성은 항상 있지만 테스트는 계속 진행됩니다) 통합 테스트가 유용한 곳). ClientAPI를 사용한 1 : 1 매핑 이기 때문에 하나의 유효한 구현에서 다른 구현으로 변경하기 전의 관심사는 실제로 적용되지 않습니다 Client.의 각 메소드에 대해 하나의 유효한 구현 만 있습니다.
그러나 나는 여전히 Wrapper수업에 갇혀 있습니다. 다음과 같은 옵션이 있습니다.
Client클래스를 스텁 아웃하고 적절한 메소드가 호출되는지 테스트합니다. 이 방법으로 위와 동일한 작업을 수행하지만ClientAPI의 독립형으로 취급합니다 . 이것은 내가 시작한 곳을 바로 돌려줍니다. 다시 한번, 이것은 인터페이스가 아닌 테스트 구현의 불편한 느낌을줍니다. 은Wrapper아주 잘 완전히 다른 클라이언트를 사용하여 구현 될 수있다.나는 모형을 만듭니다
Client. 이제는 그것을 조롱하는 데 얼마나 멀리 갈지를 결정해야합니다. 서비스의 완전한 모의를 만들려면 많은 노력이 필요합니다 (라이브러리 자체에 들어간 것보다 더 많은 작업). API 자체는 간단하지만 서비스는 상당히 복잡합니다 (기본적으로 해당 데이터에 대한 작업이있는 데이터 저장소입니다). 그리고 다시, 내 목을 실제와 동기화해야합니다Client.적절한 HTTP 요청이 수행되고 있는지 테스트합니다. 즉 , HTTP 요청을하기 위해
Wrapper실제Client객체를 통해 호출 하므로 실제로 테스트하지는 않습니다. 이것은 약간 끔찍한 단위 테스트입니다.
따라서 나는 이러한 솔루션 중 어느 것에도 만족하지 않습니다. 당신은 무엇을 하시겠습니까? 이것에 대해 올바른 방법이 있습니까?