[unit-testing] 중복 된 코드는 단위 테스트에서 더 견딜 수 있습니까?

중복 된 코드는 다른 코드와 마찬가지로 단위 테스트 코드에서도 냄새가납니다. 테스트에서 중복 된 코드가있는 경우 업데이트 할 테스트 수가 불균형하기 때문에 구현 코드를 리팩토링하기가 더 어려워집니다. 테스트는 테스트중인 코드에 대한 작업을 방해하는 큰 부담이 아니라 자신있게 리팩터링하는 데 도움이됩니다.

복제가 조명기 설정에있는 경우 setUp방법 을 더 많이 사용 하거나 더 많은 (또는 더 유연한) 생성 방법을 제공하는 것을 고려하십시오 .

중복이 SUT를 조작하는 코드에있는 경우 소위 여러 “단위”테스트가 정확히 동일한 기능을 실행하는 이유를 스스로에게 물어보십시오.

중복이 어설 션에있는 경우 사용자 지정 어설 ​​션 이 필요할 수 있습니다 . 예를 들어 여러 테스트에 다음과 같은 어설 션 문자열이있는 경우

assertEqual('Joe', person.getFirstName())
assertEqual('Bloggs', person.getLastName())
assertEqual(23, person.getAge())

그렇다면 아마도 단일 assertPersonEqual메소드 가 필요할 것 assertPersonEqual(Person('Joe', 'Bloggs', 23), person)입니다. (또는 단순히에서 같음 연산자를 오버로드해야 할 수도 있습니다 Person.)

언급했듯이 테스트 코드를 읽을 수 있어야합니다. 특히 테스트 의 의도 가 분명한 것이 중요합니다 . 많은 테스트가 거의 동일하게 보이는 경우 (예 : 줄의 3/4이 동일하거나 거의 동일)주의 깊게 읽고 비교하지 않고 중요한 차이점을 찾아 내고 인식하기가 어렵습니다. 따라서 모든 테스트 방법의 모든 행이 테스트 목적과 직접 관련이 있기 때문에 중복을 제거하기위한 리팩토링 이 가독성에 도움이 된다는 것을 알게되었습니다 . 이것은 독자들에게 직접적으로 관련된 줄과 단지 상용구 인 줄의 무작위 조합보다 훨씬 더 유용합니다.

즉, 때때로 테스트는 유사하지만 여전히 상당히 다른 복잡한 상황을 실행하며 중복을 줄이는 좋은 방법을 찾기가 어렵습니다. 상식 사용 : 테스트를 읽을 수 있고 의도를 명확하게하고 테스트에서 호출 한 코드를 리팩토링 할 때 이론적으로 최소한의 테스트 이상을 업데이트해야하는 것에 익숙하다면 불완전 성을 받아들이고 이동합니다. 좀 더 생산적인 것입니다. 나중에 영감이 떠오르면 언제든지 돌아와서 테스트를 리팩토링 할 수 있습니다!

답변