단위 테스트에 대한 실행 순서를 시행하는 것은 나쁜 습관입니까?

여러 하위 모듈로 구성된 프로젝트에 대한 테스트를 작성 중입니다. 내가 작성한 각 테스트 사례는 서로 독립적으로 실행되며 테스트 사이의 모든 데이터를 지 웁니다.

테스트는 독립적으로 실행되지만 일부 경우 하나 이상의 하위 모듈이 필요하므로 실행 순서를 시행하는 것을 고려하고 있습니다. 예를 들어, 서브 모듈이 데이터를 생성하고 있고 다른 모듈이 데이터에 대해 쿼리를 실행하고 있습니다. 데이터를 생성하는 서브 모듈에 오류가 있으면 서브 모듈 자체가 제대로 작동하더라도 쿼리 서브 모듈에 대한 테스트도 실패합니다.

테스트중인 주요 기능은 첫 번째 하위 모듈에서만 데이터를 가져 오는 블랙 박스 원격 서버에 대한 연결이므로 더미 데이터로 작업 할 수 없습니다.

이 경우 테스트 실행 순서를 적용해도 괜찮습니까? 아니면 나쁜 습관입니까? 이 설정에서 냄새가 나는 것 같지만 더 나은 방법을 찾을 수 없습니다.

편집 : 문제는 하나의 테스트가 다른 테스트의 설정 인 테스트를 구성하는 방법에 있습니다. "이전"테스트는 설정이 아니라 설정을 수행하는 코드를 테스트합니다.

테스트중인 주요 기능은 첫 번째 하위 모듈에서만 데이터를 가져 오는 블랙 박스 원격 서버에 대한 연결이므로 더미 데이터로 작업 할 수 없습니다.

이것이 저에게 중요한 부분입니다. "유닛 테스트"와 "서로 독립적으로 실행"에 대해 이야기 할 수 있지만,이 원격 서버에 의존하고 "제 1 서브 모듈"에 의존하는 것처럼 들립니다. 따라서 모든 것이 단단히 결합되고 외부 상태에 따라 달라집니다. 따라서 실제로 통합 테스트를 작성하고 있습니다. 이러한 테스트는 외부 요인에 크게 의존하기 때문에 특정 순서로 실행되는 것은 매우 정상적인 일입니다. 문제가 발생하면 테스트 실행을 조기에 종료 할 수있는 주문 테스트 실행은 통합 테스트에 완벽하게 허용됩니다.

그러나 앱의 구조를 새롭게 살펴볼 가치가 있습니다. 첫 번째 서브 모듈과 외부 서버를 모의 할 수 있으면 다른 모든 서브 모듈에 대해 실제 단위 테스트를 작성할 수 있습니다.

예, 그것은 나쁜 습관입니다.

일반적으로, 단위 테스트는 단일 코드 단위 (예 : 알려진 상태에 기반한 단일 함수)를 테스트하기위한 것입니다.

야생에서 발생할 수있는 일련의 이벤트를 테스트하려는 경우 통합 테스트와 같은 다른 테스트 스타일을 원합니다. 타사 서비스를 사용하는 경우 더욱 그렇습니다.

이와 같은 것을 단위 테스트하려면 더미 데이터를 삽입하는 방법을 찾아야합니다 (예 : 웹 요청을 미러링하지만 로컬 더미 데이터 파일에서 알려진 데이터를 반환하는 데이터 서비스 인터페이스 구현).

제안 된 강제 실행 순서는 첫 번째 실패 후 테스트 실행을 중단 한 경우에만 의미가 있습니다.

첫 번째 실패에서 테스트 실행을 중단하면 각 테스트 실행에서 단일 문제 만 발견 할 수 있으며 이전의 모든 문제가 해결 될 때까지 새로운 문제를 찾을 수 없습니다. 첫 번째로 실행할 테스트에서 수정하는 데 한 달이 걸리는 문제가 발견되면 해당 달 동안 테스트가 실제로 실행되지 않습니다.

첫 번째 실패에서 테스트 실행을 중단하지 않으면 실패한 각 테스트를 조사해야하므로 강제 실행 순서는 아무것도 사지 않습니다. 데이터 생성 서브 모듈에서도 식별 된 실패로 인해 쿼리 서브 모듈에 대한 테스트가 실패하고 있음을 확인하는 경우에도 마찬가지입니다.

내가 줄 수있는 최선의 조언은 종속성의 실패로 인해 테스트가 실패 할 때 쉽게 식별 할 수있는 방식으로 테스트를 작성하는 것입니다.

당신이 말하는 냄새는 테스트에 잘못된 제약 조건과 규칙을 적용하는 것입니다.

단위 테스트는 종종 "자동 테스트"또는 "프로그래머에 의한 자동 테스트"와 혼동됩니다.

단위 테스트는 작고 독립적이어야하며 빠릅니다.

어떤 사람들은 이것을 "프로그래머가 작성한 자동 테스트는 작고 독립적이어야한다"고 잘못 읽었습니다 . 그러나 이는 테스트가 작고 독립적이며 빠르지 않은 경우 단위 테스트가 아니므로 단위 테스트 규칙 중 일부는 테스트에 적용 되지 않아야 하거나 적용 할 수 없음 을 의미합니다. 사소한 예 : 매번 빌드 한 후에 단위 테스트를 실행해야합니다.이 테스트는 빠르지 않은 자동화 된 테스트에는 수행하지 않아야합니다.

테스트가 단위 테스트가 아니라는 것은 하나의 규칙을 건너 뛸 수 있고 테스트 사이에 상호 의존성을 가질 수 있음을 의미하지만, 다른 질문의 범위를 위해 놓칠 수있는 다른 규칙이 있음을 발견했습니다 .

위에서 언급했듯이 실행중인 것은 통합 테스트 인 것처럼 보이지만 다음과 같이 말합니다.

예를 들어, 서브 모듈이 데이터를 생성하고 있고 다른 모듈이 데이터에 대해 쿼리를 실행하고 있습니다. 데이터를 생성하는 서브 모듈에 오류가 있으면 서브 모듈 자체가 제대로 작동하더라도 쿼리 서브 모듈에 대한 테스트도 실패합니다.

리팩토링을 시작하기에 좋은 장소 일 수 있습니다. 데이터에서 쿼리를 실행하는 모듈은 첫 번째 (데이터 생성) 모듈의 구체적인 구현에 의존해서는 안됩니다. 대신 해당 데이터를 얻기위한 메소드가 포함 된 인터페이스를 삽입하는 것이 좋으며 쿼리 테스트를 위해이를 조롱 할 수 있습니다.

예 :

당신이 가지고 있다면:

class Queries {

    int GetTheNumber() {
        var dataModule = new Submodule1();
        var data = dataModule.GetData();
        return ... run some query on data
    }
}

대신 다음을 선호하십시오.

interface DataModule {
    Data GetData();
}


class Queries {

    IDataModule _dataModule;

    ctor(IDataModule dataModule) {
       _dataModule = dataModule;
    }

    int GetTheNumber() {
        var data = _dataModule.GetData();
        return ... run some query on data
    }
}

이렇게하면 데이터 소스의 쿼리에서 종속성이 제거되고 특정 시나리오에 대해 쉽게 반복 가능한 단위 테스트를 설정할 수 있습니다.

다른 답변은 테스트 순서가 좋지 않다는 것을 언급하지만 (대부분의 경우) 테스트 실행 순서를 시행 해야하는 한 가지 좋은 이유가 있습니다. 다른 외부 리소스에 의존하지 않습니다). 이를 통해 더 많은 테스트를 더 빠르게 수행 할 수 있으므로 피드백 루프 속도가 빨라질 수 있습니다.