단위 테스트를 구현하기 위해 Easymock (또는 이와 유사한 조롱 프레임 워크)을 사용할 때 상호 의존성 테스트를해야합니다 (내 의존성 상태를 주장하지 않기 때문입니다.).상태 기반 테스트와 반대로 상호 작용 기반 테스트를 수행하는 것이 적절한 경우는 언제입니까?
한편 손으로 쓰는 스텁 (easymock을 사용하는 대신)을 사용하면 상태 기반 테스트를 구현할 수 있습니다.
상호 작용 기반 테스트 또는 상태 기반 테스트를 원한다면 상당히 명확하지 않습니다.
저는 편견적이고 Easymock을 사용하고 싶지만 앞으로 발생할 수있는 부작용이 있는지 확실하지 않습니다.
아무에게도이를 알려 주실 수 있습니까?
미리 감사드립니다.
단위 테스트 개념이 과대 평가되었다고 말하고 싶습니다. 필자는 자동화 된 테스트에 대한 아이디어를 매우 좋아하지만, 시스템/서브 시스템 전체가 아닌 하나의 유닛 만 테스트한다는 인공적인 요구 사항을 좋아하지 않습니다.
즉, 객체가 본질적으로 인터페이스 및을 통해 상기 종속성과 상호 작용하도록 빌드 할 때 상호 작용을 테스트해야합니다. 인터페이스의 구현이 다양 할 것입니다. 이 경우 특정 인터페이스 구현의 구현 세부 사항을 고려 대상에서 제외하려고합니다.
그러나 인터페이스가 있지만 "향후 확장 예정일"인 경우 - 가까운 미래에 두 번째 구현이 없을 경우에만 기존의 개체 만 테스트 할 수 있습니다. 의존성 구현. 인터페이스를 제대로 조롱하는 데 필요한 추가 노력은 이점보다 더 많은 버그를 줄 것입니다.
둘 다 할 수있는 이유가 없습니다. mocks를 사용하여 행동 기반 또는 상호 작용 기반 테스트를 수행하면 원하는 모든 것이 테스트 동작 일 때 많은 상용구를 절약 할 수 있습니다. 손으로 쓰는 스텁을 사용하면 테스트를 거쳐야하는 메서드가 호출되었음을 알리는 많은 부울이 생깁니다. 그것은 중복되고, 부서지기 쉽고 굉장히 끌립니다.
한편, 때때로 상태를 테스트하려고합니다. 예를 들어, 조롱 대상 또는 스터 빙 후보자의 상태에 따라 테스트중인 객체의 동작을 변경해야하는 경우 작업 할 복잡한 상호 작용이 있습니다.
그런 경우 조롱 프레임 워크가 방해가 될 수 있으며 손으로 직접 작성한 스텁을 사용하면 테스트 목적에 따라 상태를 훨씬 쉽게 관리 할 수 있습니다.
그래서 결론은 상호 배타적이지 않다는 것입니다. 주어진 테스트에서 의미가있는 것을 사용하십시오. 각 테스트가 작고 한 가지만 테스트하면 (합리적인만큼) 모의 테스트를 시작한 상황에서 갑자기 일을 되 찾으려는 노력을해야한다는 것을 알게됩니다. 스텁에.
개체를 도메인 값 개체 (상태를 유지하며 변경 불가능해야 함) 및 서비스로 나누어야합니다. 서비스는 다른 객체가 특정 작업을 수행하기 위해 물어야하는 항목이지만 코드가이 작업의 수행 방법에 대해 염려하지 않아야합니다. 피어를 테스트하지 않고 분리하여 서비스를 테스트하려면 모의를 사용하십시오.
계산과 같은 도메인 기능을 포함 할 수있는 값 개체는 책임을 계산하고 위임하지 않으므로 조롱하면 안됩니다.
잘 설계된 시스템에서는 서비스가 항상 주입되어야하며 다른 서비스에서 반환되지 않으므로 일반적으로 모의도는 mock을 반환하지 않아야합니다.