유지 관리 가능한 테스트 작성: 단위 테스트의 과잉 사양
오늘 글을 쓰게 되어 기쁩니다.
오늘 우리는 단위 테스트에서 Overspecification의 개념으로 유지 가능한 테스트 작성에 대한 부분을 마칠 것입니다. 그럼 다이빙합시다.
Overspecified Test 란 무엇입니까?
Roy에게서 이것을 읽으십시오
An overspecified test is one that contains assumptions about how a specific unit under test (production code) should implement its internal behavior, instead of only checking that the end behavior is correct.
단순히 우리가 테스트 중인 장치의 최종 동작보다 내부적인 것에 집중할 때 과도하게 지정된 테스트를 작성하고 있다고 말했습니다.
과도하게 지정된 테스트의 패턴
우리는 구체적으로 각각을 볼 것입니다
1. 순수한 내부 행동 지정하기
내부 상태는 최종 동작보다 더 자주 변경될 수 있습니다. 내부 상태에 대한 단위 테스트를 작성하는 경우 깨지기 쉬운 단위 테스트를 작성하는 것입니다.
아래 코드는 그것을 보여줍니다 :
[Test]
public void Initialize_WhenCalled_SetsDefaultDelimiterIsTabDelimiter()
{
LogAnalyzer log = new LogAnalyzer();
Assert.AreEqual(null,log.GetInternalDefaultDelimiter());
log.Initialize();
Assert.AreEqual('\t', log.GetInternalDefaultDelimiter());
}
😳 Initialize 메서드를 테스트하는 이유는 최종 동작에 가치가 있습니까? 때때로 아니오 😒 .
Roy가 말하는 것보다 더 좋은 말은 없습니다.
This test is overspecified because it only tests the internal state of the LogAnalyzer object. Because this state is internal, it could change later on. Unit tests should be testing the public contract and public functionality of an object. In this example, the tested code isn’t part of any public contract or interface
2. 필요하지 않은 경우 추정 및 주문 또는 정확히 일치
나는 그것을 인정하고, 때때로 나는 그것을했고, 특정 문자열 메시지에 대해 주장하고 요구 사항이 변경되면 메시지도 변경되고 내 단위 테스트가 중단됩니다. 따라서 간단한 질문은 string.Equals() 대신 string.Contains()를 사용할 수 있습니까?
The same goes for collections and lists. It’s much better to make sure a collection contains an expected item than to assert that the item is in a specific place in a collection (unless that’s exactly what’s expected).By making these kinds of small adjustments, you can guarantee that as long as the string or collection contains what’s expected, the test will pass. Even if the implementation or order of the string or collection changes, you won’t have to go back and change every little character you add to a string.
간단하고 명확하며 이해할 수 있습니다. 😜
3. 스텁을 목으로도 사용하기
여기서 주요 단어는
As long as the end value still holds, your test shouldn’t care that something internal was called or not called at all.
The End Behaviour, The End Behviour, The End Behavior, 최종 행동을 달성하기 위한 내부적 방법은 중요하지 않고 변경할 수 있지만 최종 사용자가 원하는 것은 최종 행동입니다.
읽어주셔서 감사합니다 😊. 질문이 있으시면 언제든지 저에게 글을 남겨주세요.
By the Grace of JESUS ❤️ Readable Unit Tests에 대한 또 다른 게시물 시리즈를 시작하겠습니다.
Reference
이 문제에 관하여(유지 관리 가능한 테스트 작성: 단위 테스트의 과잉 사양), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/edgaremmanuel/writing-maintainable-tests-overspecification-in-unit-tests-2lak텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)