하지만 일반적으로 테스트 라이브러리는 재사용 가능한 라이브러리가 아니며, 사용할 클라이언트도 이미 알고 있습니다. 즉, 비주얼 스튜디오에 내장된 테스트 실행기(test runner)나 지속적 통합 서버에서 제공하는 테스트 실행기 등 2~3개의 표준 테스트 실행기 정도가 될 것입니다.
규칙에 대한 문서에는 어떤 경우에 해당 규칙을 적용하지 않아도 괜찮은지 설명하는 부분도 있는데, 유닛 테스트 라이브러리가 이 설명에 부합합니다. 따라서 해당 규칙을 제거해 테스트에서 불필요한 잡음을 없앨 수 있습니다.
유닛 테스트 단계에서는 이런 규칙을 꺼두는 것이 좋지만, 제품을 위한 코드에서는 반드시 켜두어야 합니다. 이 부분을 제외한 특성화 테스트 코드가 예제 4-3입니다.
예제 4-1의 또 다른 문제는 GetAsync 메서드에서 Uri 객체 대신 string을 오버로드해서 사용하고 있다는 점입니다. 테스트는 new Uri("", UriKind.Relative) 대신 ""를 사용하면 더욱 읽기 쉬울 것입니다. 물론 또 다른 정적 코드 분석 규칙10은 이런 형태의 오버로드를 권장하지 않습니다.
‘문자열 형식’[3] 코드를 피해야 합니다11. 문자열 대신 적절하게 캡슐화된 객체를 사용하는 것이 좋습니다. 저는 이 원칙이 중요하다고 생각하기 때문에 ConfigureAwait에서 보았던 것처럼 해당 규칙을 꺼둘 생각은 없습니다.