TDD Mock 통화 확인-안티 패턴입니까?

나는 1 년 동안 TDD를 해왔고, 그것에 대해 꽤 기분이 좋고, 테스트 스위트를 좋아합니다. 그러나 최근에 많은 모의 통화 확인을 수행하고 있음을 알았습니다. 예를 들어 리포지토리를 주입 할 서비스가 있습니다. 단위 테스트에서 리포지토리를 모의 테스트하고 테스트하는 메소드 내에서 호출되었는지 확인합니다. 그런 다음 반환 된 결과가 올바른지 확인합니다 (다른 테스트에서). 내 단위 테스트가 이제 구현 세부 사항과 매우 관련되어 있기 때문에 이것은 분명히 "느낀다". 나는 당신이 "행동"을 테스트해야한다고 들었습니다. 그러나 많은 상황에서 ... 가능하지 않습니다. 당신이 있다면void예를 들어, 일반적으로 부작용을 테스트합니다. 나는 이것을 쉽게 보여줄 수있는 간단한 코드 카타를 보여주기 쉽지만 IMHO는 우리가 작성하는 실제 프로그램에 잘 반영되지 않습니다. 내가 뭘 잘못하고 있니? 이런 유형의 테스트는 일종의 반 패턴입니까? 이것에 대한 귀하의 의견에 감사 드리며, TDD에 관해서는 여전히 초보자입니다.

글쎄, 당신은 입력과 출력을 테스트하려고합니다. 외부에서 보이는 행동을 확인해야합니다. 수업이하는 "약속"또는 "계약".

동시에 때로는 말한 것을하는 것보다 방법을 테스트하는 더 좋은 방법이 없습니다.

나는 그것이 테스트를 더 취하기 쉽게 만든다고 생각하므로 가능하면 구현 세부 사항에 의존하는 테스트를 피해야하지만 전혀 또는 아무것도 아닌 거래는 아닙니다. 때로는 최악의 경우 구현을 변경하고 테스트를 업데이트해야합니다.

테스트의 목적은 가능한 생산적인 구현을 제한하는 것입니다. 실제로 필요한 구현에만 제한을 두어야합니다. 일반적으로이는 어떤 프로그램이해야 할, 그리고 어떻게 그것을 않습니다.

예를 들어 서비스가 저장소에 무언가를 추가하는 경우 추가 조치가 트리거되지 않고 나중에 새 항목이 저장소에 포함되는지 테스트해야합니다.

이것이 작동하려면 서비스 테스트에서 저장소 구현 (다른 곳에서 테스트)을 사용할 수 있어야합니다. 공동 작업자의 실제 구현을 사용하는 것이 일반적으로 가장 좋은 접근 방법이라는 것을 알았습니다. 왜냐하면 실제로 가장 좋은 구현이기 때문입니다.

"그러나 테스트에서 실제 구현을 사용하는 것이 비용이 많이 든다면 (예 : 설정하기 복잡한 자원이 필요하기 때문에)이 경우 모의를 사용해야합니까?"

어쨌든 실제 구현이 함께 작동하는지 테스트하는 통합 테스트를 원할 것입니다. 이 하나의 통합 테스트만으로도 서비스를 테스트 할 수 있습니다. 즉, 서비스가 많은 공동 작업자를 연결하면 (따라서 테스트하기 어려운 경우) 논리가 포함되어 있지 않은지 확인하십시오. 필요한 경우 다중 (통합) 테스트가 필요한 경우 코드의 구조를 변경해야합니다 (예 : 논리를 분리하여 더 테스트 가능하도록).

이 경우 모의 객체를 사용하면 잘못 격리 된 로직을 테스트하는 데 따르는 어려움을 덜어 주므로 구조적인 문제를 숨길 수 있습니다 . 따라서 모의를 사용하여 잘못 구조화 된 코드를 테스트하지 말고 대신 구조를 수정하십시오.

내 생각은 '집계 서비스'입니다.

전화 확인은이 작업을 수행하지만 많은 가치를 제공하지는 않습니다. 배선 확인 중입니다.

이것에 대한 비 독점적이고 다른 3 가지 방법이 있습니다 :

1. 더 높은 수준의 행동을 확인할 수 있도록 각 개별 서비스에 대한 테스트를 확장하십시오. 예를 들어, 서비스의 단위 테스트에서 메모리 내 데이터베이스에 충돌하는 경우 실제 db에 대해 서비스를 테스트 할 수 있도록 레벨을 올리십시오. 서비스 계층은 추상화 트리보다 높으므로 테스트해야합니다.

2. 코드 생성을 사용하여 집계 된 서비스에서 직접 서비스를 작성하십시오.

3. 일종의 리플렉션 또는 동적 언어를 사용하여 동일한 작업을 수행하십시오. 예를 들어, Java에서는 호출을 직접 전달하는 groovy 인터페이스를 사용할 수 있습니다.

이 작업을 수행하는 다른 방법이있을 수 있지만 배선을 확인하는 것만으로 지불금이 매우 낮아이 구현에 어려움을 겪을 수 있습니다.