단위 테스트에서 코드 품질?

단위 테스트를 작성할 때 코드의 품질과 가독성을 높이기 위해 추가 시간을 소비 할 가치가 있습니까?

테스트를 작성할 때 나는 더 빠른 쓰기와 많은 변수 사용을 피하기 위해 종종 Demeter of Law를 위반 합니다. 기술적으로 단위 테스트는 직접 재사용되지 않습니다. 코드에 엄격하게 바인딩되어 있으므로 많은 시간을 할애 할 이유가 없습니다. 그들은 단지 기능적 일 필요가있다.

품질과 가독성 측면에서 생산 코드보다 단위 테스트를 잘 관리하지 않으면 동일하게 처리해야합니다. 단위 테스트는 종종 일부 코드의 기능을 파악하려고 할 때 가장 먼저 확인해야하며 독자는 테스트를 볼 때 문제가되는 부분을 빨리 이해해야합니다. 단위 테스트는 또한 많이 바뀌는 경향이 있으며, 설계가 견고하지 않은 경우 많이 중단되어 테스트를 통해 얻을 수있는 이점이 사라집니다.

데메테르의 법칙을 위반하는 것은 분명히 그 이유에 대한 당신의 단위 테스트와 내 마음에서 나오는 다른 두 가지 문제입니다.

• 테스트가 Arrange 또는 Act 섹션 에서 Demeter of Law를 위반하는 경우 단위 테스트는 코드의 다른 소비자 일 뿐이므로 테스트중인 클래스를 호출하고 작동시킬 것이므로 프로덕션 코드도 마찬가지입니다. 다른 생산 코드와 같은 방식으로

• 테스트가 Assert 섹션에서 Demeter of Lawmeter를 위반하는 경우 (즉, 테스트중인 오브젝트의 종속성 그래프에 깊게 중첩 된 값을 확인하는 경우) 실제로 단위 테스트가 아닌 통합 테스트 일 수 있습니다. 즉, TestA에서 ABCD가 무언가와 같다고 주장하는 경우 실제로 A가 아닌 D와 A 를 테스트하려고 할 수 있습니다 .

그건 그렇고, 말할 때

빠른 쓰기와 너무 많은 변수를 사용하지 않기 위해 Demeter of Lawer를 자주 사용합니다.

당신은 글을 알고 있어야

var grab = myDependency.Grab;
var something = grab.Something;
var very = something.Very;

very.Deep();

현명한 데 메타보다 현명하지 않다

myDependency.Grab.Something.Very.Deep();

그것이 당신이 의미 한 것이라면.

단위 테스트를 위해 양질의 코드를 작성하는 데 시간을 투자 할 가치가 있습니다.

• 다른 코드와 마찬가지로 유지 관리가 필요합니다.
• 단위 테스트는 시스템에 가장 적합한 문서 소스 중 하나이며, 가장 신뢰할 수있는 형식입니다. 그들은 정말로 보여 주어야한다 :
  • 의도 : "예상되는 행동은 무엇입니까?".
  • 사용법 : "어떻게이 API를 사용해야합니까?".
• 다른 코드와 마찬가지로 디버깅이 필요합니다.

약간 더 임시 접근 방식을 선호하는 한 가지 요소는 단위 테스트가 공개 API가 될 수 없으므로 인터페이스 등을 걱정할 필요가 없다는 것입니다. 당신은 노출하고 있습니다.

그렇습니다. 단위 테스트를 다른 코드와 비슷한 표준으로 유지해야하는 몇 가지 이유가 있습니다.

• 각 단위 테스트는 또한 피검 인의 문서 역할을합니다. 테스트가 포괄적이고 가능한 많은 경우와 오류 조건을 포괄 할 때 클래스 나 함수의 주석 문서를 대체 할 수 있습니다. 또한 코드 기반을 처음 사용하는 사람들을위한 출발점 역할을 할 수 있습니다.

• 단위 테스트도 버그가있을 수 있습니다. 코드가 잘 작성되면 오류가 더 잘 보입니다.

• 어떤 이유로 나중에 모듈을 분할해야하는 경우 단위 테스트도 분할해야합니다. 쉽게 식별 할 수있는 종속성을 갖도록 테스트를 작성하면 더 쉽습니다.

즉, 항상 실용성 문제가 있습니다. 코드의 언어와 특성에 따라 테스트 할 코드보다 테스트에 더 많은 시간을 소비하지 않으면 서 "깨끗한"단위 테스트를 작성하기가 어려울 수 있습니다. 이 경우에는 일반적으로 전체 범위에 대해 너무 걱정하지 않고 쉽고 빠른 물건과 가장 중요한 기능을 테스트합니다. 나중에 버그가 발생할 때마다 테스트를 작성하고 새로운 테스트와 기존 테스트를 리팩토링하여 더 좋게 만들 수 있는지 확인합니다.

unittest를 읽을 수없고 다음에 실패 할 때 테스트중인 항목을 찾을 수없는 경우 디버깅 시간을 두 배로 소비합니다 (한 번 테스트에 대해 알아보고 테스트 한 코드를 수정하기 위해 한 번).

솔직히 unittests는 예상 된 결과를 가져야합니다. 절차를 수행하십시오. 실제 결과를 얻는다; 작성하고 이해하기 쉬운 실제 구조 유형에 대해 예상되는 테스트

테스트 코드는 프로덕션 코드만큼이나 사랑을 받아야합니다. 가독성을 위해, 아마도 더 많을 것입니다. 본인 이외의 사람 (코드를 떠난 후 2 주를 포함하여)이 무슨 일이 일어나고 있는지 이해해야한다면 코드를 선명하게 만들어야합니다.

이것은 다음을 의미합니다.

• 테스트 데이터 빌드를 빌더 클래스로 추출하십시오.
• 여러 개의 어설 션을 별도의 어설 션 방법으로 추출합니다.
• 당신의 이름은 매우 정확해야합니다. Assert.That(x4, Is.EqualTo(y16*2*SOME_VALUE), ASS_ERR_TXT_56)대부분의 독자에게는 거의 말이되지 않습니다.

극도로 취해진 테스트는 산문처럼 읽고 이해하기가 쉽도록 작성 될 수 있습니다. 극단적 인 테스터는 아마도 10 줄 이상의 단위 테스트가 나쁜 것이라고 말할 것입니다.

가장 중요한 실질적인 이유는 코드를 변경할 때마다 단위 테스트를 변경하기 때문입니다. TDD를 수행하는 경우 단위 테스트를 먼저 변경해야합니다.

테스트에서 다음 중 하나를 수행하십시오.

• 중복 코드
• 가독성 감소
• 단단한 커플 링
• 시간적 커플 링
• 높은 순환 복잡성 (많은 종속성)

그리고 당신은 변화가 필요할 때 많은 일을하고 있습니다.

당신이 제안한대로 테스트를하면 결국 후회하게됩니다. "TDD가 작동하지 않는다"는 잘못된 결론에 도달 할 수도 있습니다.

이러한 단위 테스트가 "임시"인지 여부에 따라 다릅니다. 만약

1. 테스트가 자주 사용됩니다.

2. 개발자는 다른 개발자가 작성한 단위 테스트로 작업해야합니다.

3. 대부분의 테스트는 단위 테스트로 수행됩니다.

그런 다음 테스트를 올바르게 작성해야합니다. 테스트 자체에 버그가있는 경우, 특히 테스트가 작성된 후 일정 시간이 지나면 버그를 찾아 수정하기가 어렵습니다.

반면에 이러한 테스트가 개발자 자신 만 사용하는 경우 괜찮습니다. 그러나 여전히 '판독 가능'코드를 작성하는 것이 더 바람직합니다. 래칫 괴물이 말했듯이, 테스트를 작성하는 데 쓰는 것보다 테스트를 수정하는 데 더 많은 시간을 할애 할 것입니다.