고품질 테스트 작성

안타깝게도 테스트는 여전히 많은 조직에서 마땅히 받아야 할 관심을 받지 못하고 있습니다. 때로는 개발자가 테스트를 작성하지 않으면 죄책감을 느끼는 동시에 테스트 코드가 제대로 검토되지 않는 경우가 많습니다. 대신 리뷰에서 자주 확인하는 것이 테스트가 있는지 여부뿐인데 테스트만 하는 것만으로는 부족하다는 점이 아쉽다. 실제로 품질이 더 높지는 않더라도 적어도 프로젝트의 다른 모든 코드와 품질은 동일해야 합니다. 그렇지 않으면 테스트가 너무 자주 실패하거나, 이해하기 어렵거나, 실행하는 데 너무 오래 걸리기 때문에 테스트가 실제로 방해가 될 수 있습니다. 저장소 모의 대신 메모리 내 구현을 사용하는 방법에 대한 내 블로그 게시물에서 이러한 사항 중 일부를 이미 논의했습니다. 이제 테스트를 작성할 때 주의해야 할 좀 더 일반적인 사항에 대해 논의하고 싶습니다.

미니멀리즘이 핵심이다

Stack Overflow에서는 질문에 재현 가능한 최소한의 예제를 추가하라고 요청하는데, 제 생각에는 이는 정확히 같은 이유로 테스트를 작성하는 데에도 매우 좋은 조언입니다. 특히 테스트를 작성한 후 몇 달 후에 읽을 때, 일이 덜 발생하면 무슨 일이 일어나고 있는지 완전히 이해하는 것이 훨씬 쉽습니다. 그러니 테스트에 꼭 필요한 코드만 작성하고, 단지 쉽다는 이유만으로 더 많은 것을 추가하고 싶은 유혹을 뿌리치세요. 그러나 테스트 코드는 물론 완전해야 합니다. 즉, 테스트에는 필요한 만큼의 줄이 포함되어야 하지만 가능한 적은 줄이 포함되어야 합니다.

100% 코드 적용 범위를 찾으세요

인기 없는 의견일 수도 있지만, 많은 사람들이 이것을 나쁜 습관이라고 생각하더라도 100% 코드 적용 범위를 목표로 하는 것이 전적으로 타당하다고 생각합니다.

때때로 팀은 더 낮은 값에 만족합니다. 90%의 코드 적용 범위. 그러나 그것은 나에게 별로 의미가 없습니다. 우선, 이 모든 숫자는 다소 임의적이며 데이터를 사용하여 백업하기가 어렵습니다. 또한 새 코드를 작성할 때 해당 임계값을 통과하기 위해 코드 전체를 테스트할 필요는 없습니다. 그리고 누군가가 적용 범위를 확장했다면 다음 사람은 코드 적용 범위를 90% 이상으로 유지하면서 테스트를 전혀 작성하지 않고 빠져나갈 수 있으며, 이는 잘못된 자신감을 갖게 됩니다.

제가 자주 듣는 변명 중 하나는 getter 및 setter와 같은 간단한 함수에 대한 테스트를 작성하는 것이 말이 되지 않는다는 것입니다. 그리고 아마도 놀랍게도 나는 그 말에 전적으로 동의합니다. 하지만 문제는 다음과 같습니다. 실제로 이러한 getter 및 setter를 사용하는 테스트가 없다면 아마도 이를 사용할 필요가 없을 것입니다. 따라서 100% 테스트 적용 범위를 달성하는 것이 얼마나 어려운지에 대해 불평하는 대신, 처음부터 필요하지 않은 코드를 작성하지 않는 것이 더 나을 것입니다. 이는 또한 모든 코드 줄에 수반되는 유지 관리 부담을 방지합니다.

그러나 작은 문제가 있습니다. 코드가 이상한 일을 하는 경우가 있는데, 이로 인해 테스트 실행 중에 실행되었음에도 불구하고 코드 검사 도구가 일부 행을 발견되지 않은 것으로 표시할 수 있습니다. 나는 이와 같은 상황을 많이 겪지는 않았지만, 이 작업을 수행할 방법이 없다면 코드 적용 범위에서 제외합니다. 예: PHPUnit에서는 codeCoverageIgnore 주석을 사용하여 이를 수행할 수 있습니다.

<?php class SomeClass
{
    /**
     * @codeCoverageIgnore
     */
    public function doSomethingNotDetectedAsCovered()
    {

    }
}

이렇게 하면 코드 커버리지 분석에 이 기능이 포함되지 않아서 아직도 100% 코드 커버리지에 도달할 수 있다는 뜻이고 그 값도 계속 확인하고 있어요. 대안은 100%보다 낮은 값으로 만족하는 것이지만 위에서 언급한 것과 동일한 문제가 있습니다. 다른 코드도 테스트에서 다루지 않아 놓칠 수 있습니다.

그렇지만 100% 코드 적용이 코드에 버그가 없다는 보장을 제공하지는 않습니다. 그러나 애플리케이션 코드에 발견되지 않은 줄이 있는 경우 해당 줄에서 잠재적인 오류를 찾아내기 위해 테스트에 변경 사항을 제공하지도 않습니다.

좋은 주장을 작성하라

테스트가 작성되는 이유는 코드의 특정 동작을 확인하기 위해서입니다. 따라서 어설션은 테스트에 있어 매우 중요한 부분입니다.

물론 어설션을 작성할 때 가장 중요한 고려 사항은 코드의 동작을 올바르게 테스트한다는 것입니다. 그러나 매우 가까운 두 번째는 코드가 실패할 때 어설션이 작동하는 방식입니다. 어떤 이유로든 어설션이 실패하는 경우 문제는 개발자에게 최대한 명확해야 합니다. 이것이 명백한 상황은 현재 이 Symfony 끌어오기 요청에서 작업 중인 상황입니다. Symfony에는 기능 테스트에서 응답의 상태 코드를 확인할 수 있는 AssertResponseStatusCodeSame 메소드가 함께 제공됩니다.

<?php declare(strict_types=1);

class LoginControllerTest extends WebTestCase
{
    public function testFormAttributes(): void
    {
        $client = static::createClient();

        $client->request('GET', '/login');
        $this->assertResponseStatusCodeSame(200);

        $this->assertSelectorCount(1, 'input[name="email"][required]');
    }
}

이 테스트의 문제는 상태 코드가 200이 아닌 경우 생성되는 출력입니다. 테스트는 일반적으로 개발 환경에서 실행되므로 Symfony는 이 URL에 액세스할 때 오류 페이지를 반환하고 AssertResponseStatusCodeSame 메소드는 어설션이 실패할 경우의 전체 응답입니다. 이 출력은 HTML뿐만 아니라 CSS 및 JavaScript도 반환하고 스크롤백 버퍼가 말 그대로 너무 작아서 전체 메시지를 읽을 수 없기 때문에 엄청나게 깁니다.

이것은 지금까지 접한 최악의 예이지만, 코드에 잘못된 어설션이 사용되면 짜증스러울 수도 있습니다. 위의 AssertSelectorCount 어설션의 출력을 살펴보겠습니다. 지정된 선택기가 정확히 하나의 요소를 생성하지 않으면 다음 메시지와 함께 실패합니다.

Failed asserting that the Crawler selector "input[name="email"][required]" was expected to be found 1 time(s) but was found 0 time(s).

발생하는 문제에 대해 꽤 좋은 아이디어를 제공합니다. 그러나 주장은 다른 방식으로 작성될 수도 있습니다(집에서는 이 작업을 수행하지 마십시오!).

<?php class SomeClass
{
    /**
     * @codeCoverageIgnore
     */
    public function doSomethingNotDetectedAsCovered()
    {

    }
}

누군가는 이것이 정확히 동일하다고 주장할 수 있으므로 어떤 변형이 사용되는지는 중요하지 않습니다. 이메일에 필수 입력 필드가 하나도 없는 경우 다음 메시지가 표시되므로 이는 사실과 더 이상 다를 수 없습니다.

<?php declare(strict_types=1);

class LoginControllerTest extends WebTestCase
{
    public function testFormAttributes(): void
    {
        $client = static::createClient();

        $client->request('GET', '/login');
        $this->assertResponseStatusCodeSame(200);

        $this->assertSelectorCount(1, 'input[name="email"][required]');
    }
}

이것은 전혀 도움이 되지 않으며, 문제를 해결하려는 사람은 우선 문제가 실제로 무엇인지 파악해야 합니다. 이것이 보여주는 것은 항상 적합한 어설션을 사용해야 하며 PHPUnit에는 모든 종류의 사용 사례에 맞는 많은 어설션이 제공된다는 것입니다. 때로는 사용자 정의 어설션을 만드는 것이 타당할 때도 있습니다.

최근 몇 년간 인기를 얻은 비교적 새로운 주장은 스냅샷 테스트입니다. 특히 프론트엔드 프로젝트 작업을 시작할 때 많은 도움이 되는 것 같습니다. 나는 과거에 React와 함께 자주 사용했습니다. 주요 요점은 테스트가 다음과 같다는 것입니다.

Failed asserting that the Crawler selector "input[name="email"][required]" was expected to be found 1 time(s) but was found 0 time(s).

toMatchSnapshot 메서드에서 마법 같은 일이 일어납니다. 첫 번째 실행에서는 트리 변수의 내용을 별도의 파일에 씁니다. 후속 실행에서는 트리 값의 새 값을 이전에 별도의 파일에 저장한 값과 비교합니다. 변경된 사항이 있으면 테스트가 실패하고 스냅샷을 다시 업데이트할 수 있는 옵션과 함께 차이점이 표시됩니다. 즉, 눈 깜짝할 사이에 테스트를 수정할 수 있습니다.

정말 좋은 것 같지만 몇 가지 단점도 있습니다. 첫째, 구성 요소의 렌더링된 마크업이 변경될 때마다 테스트가 실패하기 때문에 스냅샷은 매우 취약합니다. 둘째, 작성자가 실제로 테스트하고 싶었던 것이 무엇인지 설명하지 않기 때문에 테스트 의도가 숨겨져 있습니다.

하지만 정말 마음에 들었던 점은 구성 요소를 변경할 때마다 해당 구성 요소를 사용하는 다른 모든 구성 요소를 상기시켜 준다는 것입니다. 왜냐하면 모든 스냅샷이 다음 실행에서 실패했기 때문입니다. 이런 이유로 구성 요소당 하나 이상의 스냅샷 테스트를 수행하는 것이 마음에 들었습니다.

결론

요약하자면, 테스트 품질을 향상시키기 위해 즉시 시작할 수 있는 몇 가지 일이 있다고 생각합니다.

• 테스트 코드를 반드시 필요한 최소한으로 유지하세요
• 100%의 코드 적용 범위를 목표로 하고 테스트할 수 없는 경우 코드 적용 메커니즘에서 코드를 적절하게 제외하세요
• 테스트가 실패할 때 더 나은 오류 메시지를 얻으려면 올바른 어설션을 사용하세요

제 생각에는 이러한 몇 가지 규칙을 따르는 것이 이미 큰 변화를 가져오고 오랫동안 코드 기반에서 작업하는 것을 즐기는 데 도움이 될 것입니다!

위 내용은 고품질 테스트 작성의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!