NUnit 단위 테스트의 순서를 셀 수있는 나쁜 형식입니까

저는 미친 듯이 단위 테스트를 작성해 왔고 이전 테스트에서 한 번 테스트 한 것을 무언가를 설정해야하는 경우가 종종 있습니다. 하나의 테스트 (예 : 삽입 테스트)에서 무언가 (예 : 데이터베이스 레코드)를 만든 다음 나중에 테스트 (예 : 삭제 테스트)에 사용하는 것이 합리적일까요? 아니면 각각의 모든 테스트가 항상 완전히 독립적이어야합니까?NUnit 단위 테스트의 순서를 셀 수있는 나쁜 형식입니까

NUnit에서 테스트 순서를 결정하거나 알파벳순으로 항상 수행 할 수 있습니까?

참고 : 테스트 순서에 대해 구체적으로 묻는 질문은 테스트 파일입니다. 이 아닌 테스트 파일 또는 어떤 방식 으로든 더 세계적으로.

업데이트 : 대답 모든 사람에게 감사합니다 - 좋은 답변 그룹의 감각 꽤 만장일치있는 많은에게 있었다. 가장 완벽한 설명과 많은 링크를 제공하면서 John Nolan의 답변을 선택했습니다. 당신이 짐작 했겠지만 요한처럼 "냄새 나는"것일 수도 있다고 생각하면서도이 규칙을 어 기고 싶다는 유혹에 빠져있었습니다. 또한 단위 테스트 태그를 추가 한 Fortyrunner에게도 감사드립니다.

출처

2009-01-30 Mark Brittingham

업데이트 된 사고에 대해보고하고 설명하는 것이 좋습니다. 아주 좋아. –

고마워, 존. 나는 이것이 공동체이며 공동체가 성장하고 번성하기 위해서는 어느 정도의 보살핌이 필요하다고 생각합니다. –

테스트 순서에 의존한다는 것은 테스트에서 상태가 계속 유지되고 있음을 나타냅니다. 이것은 smelly

더 깨끗한 테스트 방법은 동작을 확인하려는 단일 기능에만 의존하는 것입니다. 일반적으로 mock 테스트중인 메소드를 작동시키는 데 필요한 다른 객체가 작동합니다.

단위 테스트에 접근하는 좋은 방법은 Arrange, Act, Assert 패턴입니다.

다음은 Karl Seguin의 무료 무료 eBook에서 발췌 한 내용입니다. Arrange, Act 및 Assert를 발표했습니다. 이 상태 검사 (데이터베이스 작업에 일반적인 문제 - 나는 SO에 아니에요 때 내가 할 것입니다)이있는 경우

[TestFixture] public class CarTest 
{ 
    [Test] public void SaveCarCallsUpdateWhenAlreadyExistingCar() 
    { 
     //Arrange 
     MockRepository mocks = new MockRepository(); 
     IDataAccess dataAccess = mocks.CreateMock<IDataAccess>(); 
     ObjectFactory.InjectStub(typeof(IDataAccess), dataAccess); 
     //Act 
     Car car = new Car(); 
     Expect.Call(dataAccess.Save(car)).Return(389); 
     mocks.ReplayAll(); 
     car.Save(); 
     mocks.VerifyAll(); 
     // Assert 
     Assert.AreEqual(389, car.Id); 
     ObjectFactory.ResetDefaults(); 
    } 
}

출처

2009-01-30 23:58:03

ObjectFactory.ResetDefaults() 명령은 실제로 '어설 션'의 일부입니까? 나는 이것에 대해 생각해 보았고, 배열, 행동, 주장, 정리 또는 정리, 행동, 주장, 재설정이라고해야한다고 생각합니다. 그런 종류의, 또는 어쩌면 : 배열, 행동, 주장, disarrange? –

나는 대부분 당신과 동의하지만, 한 테스트가 다른 테스트에만 의존해야하거나 모의 객체를 사용하는 것이 테스트 프로세스의 요점을 무너 뜨릴 수있는 경우가 있습니다. 예를 들어 합리적인 것보다 더 신중한 조각으로 기능을 분할해야하거나 데이터베이스 백엔드 버전을 테스트 할 때 팀이 필요합니다. 이 경우 초기에 설정할 수있는 정적 변수를 사용하고 모든 후속 기능에서 사용할 수 있습니다. – Brain2000

@ Brain2000 나는 이것이 전통적인 의미의 '단원'테스트가 아님을 제안합니다. 나는 당신이 '기능이 합리적이라고 생각하는 것보다 더 분별력있는 조각으로 나누어진다'는 것을 의미하는지 모르겠다. 그러나 후자의 경우 상호 작용/통합 테스트에 대해 더 많이 생각하는 것처럼 보인다. 이것들에 문제는 없지만 그들은 다른 일을 수행합니다. –

나는 테스트의 순서에 정말로 의존하지 않을 것이다. 대신, 일반적인 설치 코드를 별도의 메서드로 가져와 간단한 테스트와 복잡한 테스트 모두에서 호출 할 것입니다. 또는 삭제 테스트가 시작될 때 삽입 테스트 자체를 호출하면됩니다.

출처

2009-01-30 23:38:52

각 테스트는 다른 테스트와 완전히 독립적으로 보입니다. 테스트의 순서를 정할 수 있다고해도 테스트를 변경해야하는 경우 유지 관리가 어려울 수 있습니다.

출처

2009-01-30 23:39:23 jrcs3

test fixture setups을 보면 조명기에서 테스트 전에 실행될 기능을 지정할 수 있습니다. 이렇게하면 일반 설정을 한 번 수행 할 수 있으며 하나의 테스트를 실행하든, 또는 모든 테스트를 실행하든 항상 실행됩니다.

출처

2009-01-30 23:40:24

단위 테스트의 실행 순서는 예측할 수 없거나 적어도 향후 변경 될 수 있습니다. 예 : 단위 테스트 프레임 워크가 변경되어 각 테스트가 별도의 스레드에서 실행됩니다. 테스트 순서를 사용하는 관점이 합리적이지 않습니다. 반면에 작은 독립적 인 테스트 세트를 만들어 코드의 작은 부분을 테스트 한 다음 작은 테스트를 특정 순서로 실행하는 하나 또는 여러 개의 대규모 테스트를 만들 수 있습니다.

출처

2009-01-30 23:40:39 Oleg

단위 테스트는 독립 실행 형으로 수행되며 순차 스크립트로 실행되지 않습니다. 순차적으로 실행해야 할 경우 단일 테스트 기능으로 수집하십시오.

단위 테스트에 expensive set-up이있는 경우 단위 테스트를하고 있다고 생각하면 통합 테스트를 수행 할 수 있습니다. 대부분의 단위 테스트에서 SQL 데이터베이스를 사용한다면 실제로 데이터 액세스 계층과의 통합 테스트를 수행하게됩니다.

출처

2009-01-30 23:41:42

모든 단위 테스트를 독립적으로 수행 할 것을 강력히 권고합니다.

비즈니스 로직/데이터베이스 구조 등은 시간이 지남에 따라 변경 될 수 있으므로 결국 기존 단위 테스트를 대체하거나 다시 작성해야합니다 (또는 심지어 폐기해야합니다). 다시 교체하면 불필요한 문제가 발생할 수 있습니다. 왜냐하면 다른 모든 테스트를 거치고 예상대로 작동하는지 확인해야하기 때문입니다.

또한 하나의 실패한 단위 테스트는 여러 가지 다른 테스트를 끌 수 없어야합니다 (완벽하게 작동 할 수도 있음).

출처

2009-01-30 23:49:34 ISW

, 다음은 테스트 파일 내에서 순서를 피하는 것이 절대적으로 필요하지 않다고 나에게 보인다 . 그러나 테스트 2가 2 번 테스트를 통과 한 경우 테스트 1이 통과하는 경우 2 번 테스트를 통과하면 테스트 2가 예상 된 설치를 갖지 않으므로 테스트 1이 실패하면 '치명적인'이중 실패가 발생합니다. 테스트 2가 테스트 1 통과에 달려 있다고 생각하면 테스트 1이 실패한 후 테스트 2가 통과해도 걱정하지 않으려 고합니다.

그래서 인트라 파일과 파일 간 테스트가 가능할 때마다 독립적 인 테스트를 원하게됩니다.

서로 다른 파일의 (일련의) 테스트 사이의 순서에 의존하는 것은 현명하지 않을 수 있습니다.

출처

2009-01-31 00:02:02

NUnit 단위 테스트의 순서를 셀 수있는 나쁜 형식입니까

답변

관련 문제