단일 클래스의 단위 테스트를위한 단일 또는 다중 파일?

조직에 대한 지침을 모으는 데 도움이되는 단위 테스트 모범 사례를 조사 할 때 테스트 픽스처 (테스트 클래스)를 분리하거나 단일 클래스에 대한 모든 테스트를 하나의 파일로 유지하는 것이 더 나은지 또는 유용한 지에 대한 질문을했습니다.

Fwiw, 나는 단일 단위, 테스트 당 하나의 주장, 모의 모든 의존성 등을 대상으로하는 화이트 박스 테스트라는 순수한 의미에서 "단위 테스트"를 언급하고 있습니다.

예제 시나리오는 CheckIn 및 CheckOut의 두 가지 메소드가있는 클래스 (문서라고 함)입니다. 각 방법은 동작을 제어하는 ​​다양한 규칙 등을 구현합니다. 테스트 당 하나의 어설 션 규칙에 따라 각 방법에 대해 여러 테스트를 수행합니다. DocumentTests이름이 CheckInShouldThrowExceptionWhenUserIsUnauthorizedand 인 단일 클래스 에 모든 테스트를 배치 할 수 있습니다 CheckOutShouldThrowExceptionWhenUserIsUnauthorized.

또는, 나는 두 개의 별도의 테스트 클래스를 가질 수있다 : CheckInShould와 CheckOutShould. 이 경우 테스트 이름이 짧아 지지만 특정 동작 (방법)에 대한 모든 테스트가 함께 구성되도록 테스트 이름이 구성됩니다.

나는 접근 할 수있는 찬반 양론이 있다고 확신하고 누군가가 여러 파일로 경로를 갔는지 궁금하다면 왜 그렇습니까? 또는 단일 파일 접근 방식을 선택한 경우 왜 더 나은 느낌이 들까 요?

드문 일이지만 때로는 테스트중인 특정 클래스에 대해 여러 개의 테스트 클래스를 갖는 것이 좋습니다. 일반적으로 다른 설정이 필요하고 테스트의 하위 집합에서 공유 할 때이 작업을 수행합니다.

단일 클래스에 대한 테스트를 여러 테스트 클래스로 분할해야하는 강력한 이유를 실제로 알 수 없습니다. 주도적 인 아이디어는 클래스 수준에서 응집력을 유지하는 것이므로 테스트 수준에서도 노력해야합니다. 몇 가지 임의의 이유 :

1. 설정 코드를 복제 (및 여러 버전의 유지 보수) 할 필요가 없습니다.
2. 하나의 테스트 클래스로 그룹화 된 경우 IDE에서 클래스에 대한 모든 테스트를보다 쉽게 ​​실행할 수 있습니다.
3. 테스트 클래스와 클래스 간의 일대일 매핑으로보다 쉬운 문제 해결

여러 파일에서 클래스에 대한 단위 테스트를 강제로 수행해야하는 경우 클래스 자체가 제대로 설계되지 않았 음을 나타낼 수 있습니다. 단일 책임 원칙 및 기타 프로그래밍 모범 사례를 합리적으로 준수하는 클래스에 대한 단위 테스트를 분할하는 것이 더 유리한 시나리오는 생각할 수 없습니다.

또한 단위 테스트에서 더 긴 메소드 이름을 갖는 것이 허용되지만, 방해가되는 경우 항상 단위 테스트 이름 지정 규칙을 재고하여 이름을 줄이십시오.

테스트를 여러 클래스로 분리하는 것에 대한 나의 주장 중 하나는 팀의 다른 개발자 (특히 테스트에 정통하지 않은 사람들)가 기존 테스트를 찾는 것이 더 어려워진다는 것 입니다 (이미 이미 이것에 대한 테스트가 있는지 궁금합니다. 어디 있는지 궁금합니다. ) 및 새로운 테스트를 넣을 위치 ( 이 클래스 에서이 메소드에 대한 테스트를 작성하려고하지만 새 파일 또는 기존 파일에 넣을지 확실하지 않습니다. 하나? )

테스트마다 다른 설정이 필요한 경우, TDD 실무자들이 "고정"또는 "설정"을 다른 클래스 / 파일에 넣는 것을 보았지만 테스트 자체는 아닙니다.

내가 채택하기로 선택한 기술이 처음 입증 된 링크를 기억 / 찾을 수 있기를 바랍니다. 기본적으로 테스트중인 각 멤버에 대해 중첩 된 테스트 픽스처 (클래스)가 포함 된 테스트중인 각 클래스에 대해 단일 추상 클래스를 작성합니다. 이는 원래 원하는 분리를 제공하지만 모든 테스트는 각 위치에 대해 동일한 파일에 유지됩니다. 또한 테스트 러너에서 쉽게 그룹화하고 정렬 할 수있는 클래스 이름을 생성합니다.

이 방법이 원래 시나리오에 적용되는 예는 다음과 같습니다.

public abstract class DocumentTests : TestBase
{
    [TestClass()]
    public sealed class CheckInShould : DocumentTests
    {
        [TestMethod()]
        public void ThrowExceptionWhenUserIsNotAuthorized()
        {
        }
    }

    [TestClass()]
    public sealed class CheckOutShould : DocumentTests
    {
        [TestMethod()]
        public void ThrowExceptionWhenUserIsNotAuthorized()
        {
        }
    }
}

테스트 목록에 다음과 같은 테스트가 나타납니다.

DocumentTests+CheckInShould.ThrowExceptionWhenUserIsNotAuthorized
DocumentTests+CheckOutShould.ThrowExceptionWhenUserIsNotAuthorized

더 많은 테스트가 추가되면 클래스 이름별로 쉽게 그룹화 및 정렬되어 테스트중인 클래스에 대한 모든 테스트가 함께 나열됩니다.

이 접근법의 또 다른 장점은이 구조의 객체 지향적 특성으로 인해 모든 중첩 클래스와 각 클래스 내부에서 공유되는 DocumentTests 기본 클래스의 시작 및 정리 메소드 내부에서 코드를 정의 할 수 있습니다. 포함 된 테스트의 중첩 클래스

잠시 다른 방향으로 생각하십시오.

왜 수업 당 하나의 테스트 클래스 만 가지고 있습니까? 수업 시험이나 단위 시험을하고 있습니까? 당신은 수업에 의존 합니까?

단위 테스트는 특정 상황에서 특정 동작을 테스트해야합니다. 수업에 이미 수업이 있다는 사실 CheckIn은 먼저 행동이 필요하다는 것을 의미합니다.

이 의사 코드에 대해 어떻게 생각하십니까?

// check_in_test.file

class CheckInTest extends TestCase {
        /** @test */
        public function unauthorized_users_cannot_check_in() {
                $this->expectException();

                $document = new Document($unauthorizedUser);

                $document->checkIn();
        }
}

이제 checkIn메소드를 직접 테스트하지 않습니다 . 대신 동작을 테스트하고 있습니다 (다행히;);) 리팩토링 Document하고 다른 클래스로 분할하거나 다른 클래스를 병합 해야하는 경우 테스트 파일은 일관성이 있습니다. 리팩토링 할 때 로직 만 변경하지 않고 구조 만 변경합니다.

하나의 클래스에 대한 하나의 테스트 파일은 필요할 때마다 리팩토링하기가 더 어려워지고 코드 자체의 도메인 / 논리 측면에서도 의미가 떨어집니다.

일반적으로 테스트보다는 메소드가 아닌 클래스의 동작을 테스트하는 것이 좋습니다. 즉, 일부 테스트는 예상되는 동작을 테스트하기 위해 클래스에서 두 가지 메소드를 모두 호출해야 할 수도 있습니다.

일반적으로 프로덕션 클래스 당 하나의 단위 테스트 클래스로 시작하지만 테스트하는 동작에 따라 단위 테스트 클래스를 여러 테스트 클래스로 분할 할 수 있습니다. 다시 말해 테스트 클래스를 CheckInShould와 CheckOutShould로 나누지 말고 테스트중인 장치의 동작에 따라 나누지 않는 것이 좋습니다.

1. 잘못 될 가능성을 고려하십시오

초기 개발 과정에서 수행중인 작업을 상당히 잘 알고 있으며 두 솔루션 모두 제대로 작동 할 것입니다.

훨씬 나중에 변경 후 테스트가 실패하면 더 흥미로워집니다. 두 가지 가능성이 있습니다.

1. 귀하는 심각하게 고장났습니다 CheckIn(또는 CheckOut). 이 경우에도 단일 파일 솔루션과 두 파일 솔루션 모두 정상입니다.
2. 당신은 모두 수정 한 CheckIn하고 CheckOut있지만 그들 모두 함께, 그들 각각에 맞는 방식으로 (그리고 아마도 자신의 테스트)를. 쌍의 일관성을 깨뜨 렸습니다. 이 경우 테스트를 두 파일로 나누면 문제를 이해하기가 더 어려워집니다.

2. 어떤 테스트에 사용되는지 고려하십시오

테스트는 두 가지 주요 목적을 제공합니다.

1. 프로그램이 여전히 올바르게 작동하는지 자동으로 확인하십시오. 테스트가 하나의 파일에 있는지 여러 파일에 있는지 여부는이 목적에 중요하지 않습니다.
2. 인간 독자가 프로그램을 이해하도록 도와주십시오. 밀접하게 관련된 기능에 대한 테스트를 함께 유지하면 일관성을 이해하는 것이 빠른 길이 기 때문에 훨씬 쉬울 것입니다.

그래서?

이 두 가지 관점 모두 테스트를 함께 유지하는 것이 도움이 될 수 있지만 아프지는 않습니다.