Auto Mocking 용기를 사용하는 것이 좋든 나쁘지?

Question

저는 최근에 상당히 의존성이 커지기 시작한 프로젝트에서 일하고 있습니다. AutoMocking 컨테이너를 사용하여 테스트를 약간 정리하고 덜 부서지기 쉽다는 아이디어를 모색하고 있습니다.

TDD/BDD 순수 사용자가 다음과 같이 설명하는 것에 대해 논쟁을 한 적이 있습니다. 테스트 대상에서 어떤 종속성이 필요한지 즉시 알 수 없거나 실제로 필요하지 않은 종속성을 추가 할 수 있습니다. 어느 쪽도 그들을 사용하는 것에 대한 특히 강한 논쟁처럼 들리지 않는다.

필자의 관점에서 필자는 필자가 필요에 따라 리팩토링하고, 비즈니스 요구 사항에 따라 종속성을 제거하고 도입 할 수 있도록 할 것이고, 테스트를 계속하고 코드를 컴파일하기 위해 새로운 모의/스텁을 도입 할 필요가 없습니다.

AutoMocking은 좋은/나쁜 연습으로 간주됩니까? 특정 상황을 사용해야하거나 사용해서는 안되는 특정 상황이 있습니까?

Answer 1

도구 나 프로세스와 마찬가지로 정확한 시간과 부정확 한 시간이 있습니다. 은색 총알은 없습니다. "내 일을 끝내는 데 도움이 될까?" 우리 시대의 끝에, 우리의 임무는 우리가 할 수있는 가장 큰 비즈니스 가치를 제공하는 것입니다.
그린 필드 개발을 할 때 automocking이 도움이되지 않습니다. 모든 것이 처음부터 개발되고 있으며 "전통적"조롱 기능을 갖춘 TDD/BDD 기법이 효과적입니다. 이론적으로, 의존성은 크게 변하지 않고, 언제 존재 하는지를 아는 것이 좋습니다.

유지 관리 모드 (또는 레거시 코드베이스 다루기)에서 automocking은 매우 유용 할 수 있습니다. 예를 들어 기술 부채 청산이 임무가 주어집니다. 이것은 아마도 많은 리팩토링을 필요로 할 것이고, 이러한 변경으로부터 테스트를 분리 할 수 ​​있다는 것은 엄청난 시간 절약입니다. 코드에 많은 의존성이있는 경우 SOLID 및 SOC가 손상 될 수 있으며 모든 종속성을 사용하지 않는 많은 테스트를 수행해야합니다 (또는 최소한해야 함). 이 경우 automocking은 매우 유용합니다. 물론 도움이되는 다른 많은 예가 있습니다.

어떤 도구와 마찬가지로, 그것이 신조가되지 않도록해야합니다. automocking을 활용하여 인터페이스와 api를 변경할 수 있으므로 분명히 안티 패턴입니다. 그러나 올바르게 사용하면 프로젝트 팀에 큰 도움이된다는 것을 알았습니다.

올바른 시나리오에서는 비판적인 사고와 적용이 필요합니다.

Answer 2

수동으로 종속 관계를 연결합니다 (단원 테스트에서 의존성은 매우 적은 수의 대상 객체에 대한 것임을 명심하십시오). 냄새가 났을 때 알려줍니다.이 클래스는 너무 커서 빌어 먹을 수 있어야합니다. 줄이자. 그것은 내가 자동차 조롱이 나쁘다고 생각하지 않는다고 말했다. 그러나 모든 도구가 조심스럽게 사용되어야한다.

Answer 3

자동 조롱은 의존성이 냄새를 맡기 시작하는 지점에서 유용하기 시작합니다. Skimedic의 답변과 레벨 별 의견은 같은 방향을 가리 킵니다. 따라서이 사례는 일반적으로 을 피해야합니다 (예 :). 기존/기술 부채를 없앨 수없는 경우는 예외입니다. 그러한 경우조차도, 오토 조롱이 존재하지 않는 것처럼 행동하는 것이 더 좋을 수도 있고, 팀의 속도가 떨어지면 경영진이 일부 리펙터가 정상적으로 작동한다고 생각하게하는 또 다른 이유가 될 수 있습니다. 또는 피할 수없는 유산이라면 자신의 가짜 건축업자를 프로그램하십시오. 테스트의 복잡성이 추가되면 단순히 자동 조롱을 사용하고 명백하게 간단한 테스트를 수행하는 것보다 "위험 영역"의 더 나은 표시가됩니다.

그리고 IMO에서는 새로운 코드를 사용하지 않아야합니다.