F.I.R.S.T. 유닛 테스트 작성

단원 테스트란 무엇입니까?


설계에 따르면 단원 테스트는 격리 방식으로 테스트하는 작은 코드 단원의 자동화 테스트이다.기본적으로 단원 테스트는 호출 클래스의 (public 방법으로 결과가 예상한 프로그램에 부합되는지 검사한다

단원 테스트의 장점


셀 테스트를 올바르게 작성한 경우 유지 관리 프로세스에 다음과 같은 이점이 있습니다.

  • 단원 테스트는 당신이 아직 개발하고 있을 때 오류를 발견할 수 있습니다. 만약 당신이 코드를 재구성하고 있다면, 심지어는 새로운 코드를 포함하고 있으며, 과거의 테스트가 실패하기 시작한다면, 이것은 당신이 이 방법의 행동을 바꾸었다는 것을 의미합니다. 이것은 오류를 의미할 수 있습니다.
  • 새로 발견된 결함과 관련된 수정 비용은 생산 과정에서 발견된 것보다 훨씬 낮다
  • 다시 말하면 단원 테스트는 귀하의 코드가 회귀의 영향을 받지 않도록 보호합니다. 시스템 변경은 오류가 발생할 수 있습니다
  • 코드를 변경한 후 테스트 세트를 실행해야 합니다!이렇게 하면 어떤 회귀가 존재하는지 (테스트가 실패할 경우)

  • F.I.R.S.T. 원칙


    우리가 일반적으로 프로그래밍을 하는 S.O.L.I.D. 원칙과 같이 단원 테스트의 일반적인 양호한 실천도 두 가지 원칙이 있다. 그것이 바로 F.I.R.S.T. 원칙이다.검사해 봅시다.

    [F] 아스트


    개발자는 수천 개의 단원 테스트가 있어도 개발 주기의 언제든지 테스트 세트를 실행해야 한다.그것들은 몇 초 안에 운행할 것이다.만약 하나의 테스트가 너무 오래 실행된다면, 그것은 그것보다 더 많이 할 수 있다. 따라서, 그것은 하나의 단원 테스트가 아니다.

    [1] 독립적


    어떤 주어진 단원 테스트에 대해서도 그 결과가 다른 요소의 영향을 받지 않도록 다른 모든 것에 독립해야 한다.이 정의가 있으면 그들은 통상적으로'테스트의 세 가지 A', 즉 안배, 행동, 단언('당시 제시'라고도 부른다)을 따라야 한다.

  • 스케줄: 모든 필요한 데이터는 실행할 때 테스트에 제공되어야 하며 환경에 의존해서는 안 됩니다.

  • Act: 테스트하는 실제 방법을 실행해야 합니다.

  • 단언: 단원 테스트는 하나의 결과만 테스트해야 한다. 이것은 모든 테스트는 한 대상의 한 상태가 테스트되어야 한다고 단언해야 한다는 것을 의미한다.이것은 클래스 응답의 변수만 검사해야 하는 것이 아니라 모든 테스트된 변수가 실행 방법과 관련이 있어야 한다는 것을 의미하지 않습니다.
  • [R]먹을 수 있다


    테스트는 중복성과 확정성을 가져야 한다. 환경이 어떻든지 간에 테스트를 실행할 때마다 그것들의 값은 변경할 수 없다.

    [S]elf 검증


    테스트 자체가 너에게 그것이 통과되었는지 아닌지를 알려줘야 한다.이 값들을 수동으로 검사할 필요가 없다.대부분의 단언고(예를 들어 Shouldly는 이 원칙을 지지한다.

    [T] 호로프


    당신의 테스트는 하나의 방법의 모든'쾌락 경로'xUnit를 덮어쓰고 Theory 테스트를 통해 가능하게 해야 한다), 모든 테두리 사례(테스트가 실패할 수 있다고 생각하는 곳), 불법 파라미터, 안전 결함, 큰 값.... 한 마디로 하면 모든 가능한 용례 장면을 테스트해야 한다. 100%의 코드 덮어쓰기율뿐만 아니라

    추가 T: 적시


    TDD 이후 단원 테스트는 테스트할 생산 코드를 작성하기 전에 작성해야 한다.이것은 추상적 (인터페이스) 을 작성한 다음에 방법 서명과 규범에 기초한 테스트만 통해 실현할 수 있다.테스트를 작성한 후 코드를 생성하고 테스트할 수 있습니다.

    일부 공구

    C#/.NET 개발의 경우 기본적으로 일부 도구/프레임워크를 사용할 수 있고 더 많은 도구/프레임워크는 NuGet 패키지로 사용할 수 있다.다음은 강력히 추천하는 옵션들입니다.
  • 기본 프레임워크: xUnit 는 기능이 강하고 완전한 테스트 프레임워크이다.NET, 일반적으로 VisualStudio와 함께 제공NUnit.전반적으로 말하면 둘 다 좋은 틀이지만 xUnit 읽을 수 있고 직관적이다
  • 단언 도구: Shouldly 는 본 기기의 단언류보다 직관적인 단언 테스트 결과의 방법이다.github repo는 대량의 예시를 제공했지만 아주 간단한 예시 하나만으로도 Shouldly의 가독성과 간단성을 설명할 수 있다.
  • // using Assert
    Assert.IsTrue(booleanVariable);
    // using Shouldly
    booleanVariable.ShouldBeTrue();
    
  • Mocking Tool: NSubstitute 는 특정한 클래스나 인터페이스에 mock을 생성하여 일반적인 상황에서 외부 환경(예를 들어 제3자 API나 데이터베이스)을 사용하는 방법을 쉽게 테스트할 수 있도록 하는 강력한 도구입니다.그것은 간단한 학습 곡선을 가지고 있다well documented.
  • 도구책


    이 글은 다음과 같은 다양한 출처 자료를 모아 엮은 것이다.
  • 일반적인'소프트웨어 유지보수와 진화'와'소프트웨어 테스트'이론
  • https://dzone.com/articles/writing-your-first-unit-tests
  • https://github.com/ghsukumar/SFDC_Best_Practices/wiki/F.I.R.S.T-Principles-of-Unit-Testing
  • https://medium.com/@tasdikrahman/f-i-r-s-t-principles-of-testing-1a497acda8d6
  • 좋은 웹페이지 즐겨찾기