수색…


소개

단위 테스트는 함수, 클래스, 프로 시저, 인터페이스와 같은 응용 프로그램에서 테스트 할 수있는 가장 작은 부분입니다. 단위 테스트는 소스 코드의 개별 단위를 테스트하여 사용 적합 여부를 결정하는 방법입니다. 단위 테스트는 기본적으로 코드가 설계 및 요구 사항을 충족시키고 예상대로 작동하는지 확인하기 위해 소프트웨어 개발자가 작성하고 실행합니다.

좋은 이름 지정

좋은 명명법의 중요성은 나쁜 예를 통해 잘 설명 될 수 있습니다.

[Test]
Test1() {...} //Cryptic name - absolutely no information 

[Test]
TestFoo() {...} //Name of the function - and where can I find the expected behaviour?

[Test]
TestTFSid567843() {...} //Huh? You want me to lookup the context in the database?

좋은 테스트는 좋은 이름이 필요합니다. 좋은 테스트는 방법, 테스트 시나리오 또는 요구 사항을 테스트하지 않습니다.

올바른 이름 지정은 컨텍스트와 예상되는 동작에 대한 정보도 제공합니다. 이상적으로, 빌드 머신에서 테스트가 실패하면, 테스트 코드를 보지 않고 무엇이 잘못되었는지를 결정할 수 있어야하며, 디버그해야 할 필요성이 더 커야합니다.

좋은 네이밍은 코드를 읽고 디버깅 할 시간을 절약 해줍니다 :

[Test]
public void GetOption_WithUnkownOption_ReturnsEmptyString() {...}
[Test]
public void GetOption_WithUnknownEmptyOption_ReturnsEmptyString() {...}

초보자의 경우 EnsureThat_ 또는 이와 유사한 접두어로 테스트 이름을 시작하는 것이 좋습니다. "EnsureThat_"로 시작하면 테스트가 필요한 시나리오 또는 요구 사항에 대해 생각할 수 있습니다.

[Test]
public void EnsureThat_GetOption_WithUnkownOption_ReturnsEmptyString() {...}
[Test]
public void EnsureThat_GetOption_WithUnknownEmptyOption_ReturnsEmptyString() {...}

시험 설비에도 네이밍이 중요합니다. 테스트되는 클래스 다음에 테스트 픽스쳐의 이름을 지정하십시오.

[TestFixture]
public class OptionsTests //tests for class Options
{
    ...
}

최종 결론은 다음과 같습니다.

좋은 네이밍은 좋은 테스트를 이끌어 내고 프로덕션 코드에서 좋은 디자인을 유도합니다.

단순에서 복잡한까지

작문 수업과 마찬가지로 - 간단한 경우부터 시작하여 필요에 따라 테스트 (일명 테스트) 및 구현 (일명 프로덕션 코드)을 추가합니다.

[Test]
public void EnsureThat_IsLeapYearIfDecimalMultipleOf4() {...}
[Test]
public void EnsureThat_IsNOTLeapYearIfDecimalMultipleOf100 {...}
[Test]
public void EnsureThat_IsLeapYearIfDecimalMultipleOf400 {...}

요구 사항을 다룰 때 리팩토링 단계를 잊지 마십시오. 먼저 코드를 리팩터링 한 다음 테스트를 리팩터링하십시오.

끝나면 수업에 대한 완전한 최신 READABLE 문서를 준비해야합니다.

MakeSut 개념

테스트 코드는 생산 코드와 동일한 품질 요구 사항을 갖습니다. MakeSut ()

  • 가독성 향상
  • 쉽게 리팩터링 될 수있다.
  • 의존성 주입을 완벽하게 지원합니다.

개념은 다음과 같습니다.

[Test]
public void TestSomething()
{
    var sut = MakeSut();
    
    string result = sut.Do();
    Assert.AreEqual("expected result", result);
}

가장 간단한 MakeSut ()은 테스트 된 클래스를 반환합니다.

private ClassUnderTest MakeSUT()
{
    return new ClassUnderTest();
}

의존성이 필요할 때, 여기에 주입 할 수 있습니다 :

private ScriptHandler MakeSut(ICompiler compiler = null, ILogger logger = null, string scriptName="", string[] args = null)
{
    //default dependencies can be created here
    logger = logger ?? MockRepository.GenerateStub<ILogger>();
    ...
}

MakeSut은 Testrunner 프레임 워크가 제공하는 설정 및 분해 방법에 대한 간단한 대안 일 뿐이며 이러한 방법을 테스트 특정 설정 및 분리에 적합한 장소로 활용할 수 있습니다.

모두가 자신 만의 방법으로 사용할 수 있습니다. 나를 위해 MakeSut ()은 더 나은 가독성과 유연성을 제공합니다. 마지막으로, 개념은 테스트 러너 프레임 워크와 독립적입니다.



Modified text is an extract of the original Stack Overflow Documentation
아래 라이선스 CC BY-SA 3.0
와 제휴하지 않음 Stack Overflow