깔끔한 코드 팁: 테스트는 프로덕션 코드보다 훨씬 더 잘 작성되어야 합니다.

읽고 이해하기 쉽도록 코드를 관리해야 합니다. 맞습니까? 오른쪽??

잘했어요! 👏

그러나 대부분의 개발자는 좋은 프로덕션 코드(시스템에서 실제로 실행되는 코드)를 작성하는 경향이 있지만 테스트 코드는 매우 형편없습니다.

프로덕션 코드는 실행하기 위한 것이지만 테스트는 코드를 문서화하기 위한 것이기도 합니다. 그러므로 시험 뒤에 있는 의미와 이유에 대해 의심이 있어서는 안 됩니다.
이는 또한 독자가 테스트를 통과해야 하는 방법과 이유를 이해할 수 있도록 모든 이름이 충분히 명시적이어야 함을 의미합니다.

이것은 유효한 C# 테스트입니다.

[Test]
public void TestHtmlParser()
{
    HtmlDocument doc = new HtmlDocument();
    doc.LoadHtml("<p>Hello</p>");
    var node = doc.DocumentNode.ChildNodes[0];
    var parser = new HtmlParser();

    Assert.AreEqual("Hello", parser.ParseContent(node));
}

이 테스트의 의미는 무엇입니까? 메서드 이름만 읽어도 이해할 수 있을 것입니다.

또한 여기에서 HtmlNode 개체를 만들고 있음에 유의하십시오. 이 노드 생성이 모든 테스트 메서드에 있다고 상상해 보십시오. 동일한 코드 줄을 계속해서 보게 될 것입니다.

따라서 이 테스트를 다음과 같이 리팩토링할 수 있습니다.

 [Test]
public void HtmlParser_ExtractsContent_WhenHtmlIsParagraph()
{
    //Arrange
    string paragraphContent = "Hello";
    string htmlParagraph = $"<p>{paragraphContent}</p>";
    HtmlNode htmlNode = CreateHtmlNode(htmlParagraph);
    var htmlParser = new HtmlParser();

    //Act
    var parsedContent = htmlParser.ParseContent(htmlNode);

    //Assert
    Assert.AreEqual(paragraphContent, parsedContent);
}

이 테스트는 확실히 더 좋습니다.

테스트 이름

을 읽으면 그 의미를 이해할 수 있습니다.

코드가 간결하고 일부 생성 부분이 리팩토링되었습니다

.

우리는 테스트의 3개 부분을 잘 분리했습니다: Arrange, Act, Assert(우리는 이미 그것에 대해 이야기했습니다here )

마무리

테스트는 고객이 직접 사용하지 않더라도 여전히 프로젝트의 일부입니다.

테스트를 건너뛰거나 서둘러 작성하지 마십시오. 결국, 버그를 만났을 때 가장 먼저 해야 할 일은 버그를 재현하는 테스트를 작성한 다음 동일한 테스트를 사용하여 수정 사항을 검증하는 것입니다.

그러니 테스트용으로도 좋은 코드를 계속 작성하세요!

즐거운 코딩하세요!

🐧