unit-testing
모든 언어에 대한 단위 테스트를위한 일반적인 규칙
수색…
소개
단위 테스트를 시작할 때 모든 종류의 질문이 나옵니다.
단위 테스트 란 무엇입니까? SetUp 및 TearDown이란 무엇입니까? 종속성을 어떻게 처리합니까? 왜 단위 테스트를해야합니까? 좋은 단위 테스트는 어떻게합니까?
이 기사는 이러한 모든 질문에 답하기 때문에 원하는 언어로 단위 테스트를 시작할 수 있습니다.
비고
단위 테스트 란 무엇입니까?
단위 테스트는 수행 할 작업을 수행하도록 코드를 테스트하는 것입니다. 가능한 가장 낮은 수준의 코드, 즉 클래스의 개별 메소드를 테스트합니다.
유닛이란 무엇입니까?
격리 된 상태로 테스트 할 수있는 코드의 개별 모듈. 대부분의 시간 수업과 방법. 이 클래스는 일반적으로 "테스트중인 클래스"(CUT) 또는 "테스트중인 시스템"(SUT)이라고합니다.
단위 테스트와 통합 테스트의 차이점
단위 테스트는 하나의 클래스를 실제로 독립적으로 테스트하는 행위입니다. 통합 테스트는 실제 종속성 중 하나 이상과 함께 단일 클래스를 테스트하는 행위입니다.
SetUp 및 TearDown
만들어지면 SetUp 메서드는 모든 단위 테스트 전에 실행되고 TearDown은 모든 테스트 후에 실행됩니다.
일반적으로 SetUp의 모든 전제 조건 단계와 TearDown의 모든 정리 단계를 추가합니다. 그러나 이러한 단계가 모든 테스트에 필요할 경우에만 이러한 방법을 사용하십시오. 그렇지 않은 경우, "준비"섹션의 특정 테스트 내에서이 단계를 수행하십시오.
의존성을 다루는 방법
여러 번 클래스는 다른 클래스가 해당 메서드를 실행하는 데 종속되어 있습니다. 이러한 다른 클래스에 의존하지 않으려면 위조해야합니다. 이러한 클래스를 직접 만들거나 격리 또는 모형 프레임 워크를 사용할 수 있습니다. 격리 프레임 워크는 가짜 클래스를 쉽게 만들 수있는 코드 모음입니다.
가짜 수업
CUT에서 필요로하는 의존성을 가장하는 기능을 제공하는 모든 클래스. 가짜에는 두 가지 유형이 있습니다. 스텁과 모의.
- 스텁 (Stub) : 테스트 통과 또는 실패에 아무런 영향을주지 않으며 테스트가 실행될 수 있도록 존재하는 가짜입니다.
- 모의 (mock) : CUT의 동작을 추적하고 해당 동작을 기반으로 테스트를 통과하거나 실패하는 가짜.
단위 테스트를하는 이유는 무엇입니까?
1. 단위 테스트는 버그를 발견 할 것이다.
특정 클래스에 대해 예상되는 동작이 무엇인지 정의하는 모든 테스트를 작성하면 예상대로 작동하지 않는 사항이 모두 표시됩니다.
2. 단위 테스트는 버그를 멀리 할 것입니다.
테스트를 실행할 다음 번에 버그가 발견되면 버그가 있음을 알리는 변경을하십시오.
3. 단위 테스트는 시간을 절약합니다.
단위 테스트를 작성하면 코드가 처음부터 올바르게 설계되도록 할 수 있습니다. 단위 테스트는 코드가 수행해야하는 작업을 정의하므로 수행해서는 안되는 일을하는 코드를 작성하는 데 시간을 할애하지 않습니다. 아무도 코드가 작동하지 않는다고 판단하고 자신이 작동한다고 생각하게하려면 무언가를해야합니다. 단위 테스트를 작성하는 데 시간을 할애하십시오.
4. 단위 테스트로 안심할 수 있습니다.
모든 테스트를 실행하여 코드가 정상적으로 작동하는지 확인할 수 있습니다. 코드 상태를 알면 작동하며 두려움없이 업데이트하고 개선 할 수 있다는 것은 매우 좋은 일입니다.
5. 단위 테스트는 클래스의 적절한 사용을 문서화합니다.
단위 테스트는 코드가 작동하는 방법, 예상되는 동작 및 테스트중인 코드를 사용하는 적절한 방법의 간단한 예제가됩니다.
단위 테스트를위한 일반 규칙
1. 단위 테스트의 구조에 대해서는 AAA 규칙을 따릅니다.
붙이다:
테스트 할 대상을 설정하십시오. 예상되는 결과뿐만 아니라 테스트를 실행할 수있는 변수, 필드 및 속성과 유사합니다.
Act : 실제 테스트중인 메소드 호출
주장하기 :
테스트 프레임 워크를 호출하여 "행위"의 결과가 예상 한 결과인지 확인하십시오.
2. 한 번에 한 가지만 테스트 해보십시오.
모든 클래스는 독립적으로 테스트해야합니다. 그들은 목과 스텁이 아닌 다른 것에 의존해서는 안됩니다. 다른 테스트의 결과에 의존해서는 안됩니다.
3. 간단한 "오른쪽 아래 가운데"테스트를 먼저 작성하십시오.
처음 작성하는 테스트는 가장 간단한 테스트 여야합니다. 그들은 당신이 쓰려고하는 기능을 기본적으로 그리고 쉽게 설명 할 수 있어야합니다. 그런 다음 해당 테스트가 통과되면 코드의 경계와 경계를 테스트하는보다 복잡한 테스트를 작성해야합니다.
4. 가장자리를 테스트하는 테스트를 작성하십시오.
기본 기능이 테스트되고 기본 기능이 작동하는 것을 알고 나면 가장자리를 테스트해야합니다. 좋은 일련의 테스트는 주어진 메소드에서 발생할 수있는 바깥 쪽 가장자리를 조사합니다.
예 :
- 오버플로가 발생하면 어떻게됩니까?
- 값이 0 이하로되면 어떻게 될까요?
- MaxInt 또는 MinInt에 가면 어떨까요?
- 361 도의 원호를 만들면 어떻게 될까요?
- 빈 문자열을 전달하면 어떻게됩니까?
- 문자열의 크기가 2GB이면 어떻게됩니까?
5. 경계를 넘어 테스트
단위 테스트는 주어진 경계의 양측을 테스트해야합니다. 경계를 넘어서 이동하는 것은 코드가 예측할 수없는 방식으로 실패하거나 수행 할 수있는 장소입니다.
6. 가능한 경우 전체 스펙트럼을 테스트하십시오
실용적이라면 기능에 대한 가능성을 시험해보십시오. 열거 형식이 포함 된 경우 열거 형의 모든 항목을 사용하여 기능을 테스트하십시오. 모든 가능성을 테스트하는 것은 비현실적 일 수도 있지만 모든 가능성을 테스트 할 수 있다면 그렇게하십시오.
7. 가능한 경우 모든 코드 경로를 처리하십시오.
이 역시 도전적이지만 코드가 테스트를 위해 설계되고 코드 적용 도구를 사용하는 경우 코드의 모든 행이 적어도 한 번 이상 단위 테스트로 덮 이도록 할 수 있습니다. 모든 코드 경로를 커버한다고해서 버그가 없다는 보장은 없지만 모든 코드 줄의 상태에 대한 중요한 정보를 확실히 제공합니다.
8. 버그를 나타내는 테스트를 작성한 다음 수정하십시오.
버그를 발견하면 그것을 밝혀주는 테스트를 작성하십시오. 그런 다음 밴은 테스트를 디버깅하여 쉽게 버그를 수정합니다. 그런 다음 버그가 어떤 이유로 든 다시 돌아 오면 바로 알 수 있도록 좋은 회귀 테스트를 실시합니다. 디버거에서 간단하고 직선적 인 테스트를 실행할 때 버그를 수정하는 것은 정말 쉽습니다.
여기에있는 측면 장점은 테스트를 테스트 한 것입니다. 테스트가 실패한 것을 보았으므로 테스트를 통과했음을 알았 기 때문에 테스트가 올바르게 작동한다는 것이 입증되었다는 것을 알고 있습니다. 이것은 더 나은 회귀 테스트를 만듭니다.
9. 각 테스트를 서로 독립적으로 만듭니다.
테스트는 서로 의존해서는 안됩니다. 테스트가 특정 순서로 실행되어야하는 경우 테스트를 변경해야합니다.
10. 테스트 당 하나의 주장을 씁니다.
테스트 당 하나의 주장을 작성해야합니다. 그렇게 할 수 없다면, SetUp 및 TearDown 이벤트를 사용하여 환경을 올바르게 작성하여 각 테스트를 개별적으로 실행할 수 있도록 코드를 굴절시킵니다.
11. 테스트의 이름을 명확하게 지정하십시오. 긴 이름을 두려워하지 마라.
테스트 당 하나의 주장을 수행하기 때문에 각 테스트는 매우 구체적으로 끝날 수 있습니다. 따라서 길고 완벽한 테스트 이름을 사용하는 것을 두려워하지 마십시오.
긴 완성 된 이름을 사용하면 어떤 테스트가 실패했는지 정확하게 테스트 할 수 있는지 알 수 있습니다.
길고 명확하게 명명 된 테스트도 테스트를 문서화 할 수 있습니다. "DividedByZeroShouldThrowException"테스트는 0으로 나누려고 할 때 코드가 수행하는 작업을 정확하게 문서화합니다.
12. 발생한 모든 예외가 실제로 발생하는지 테스트합니다.
코드에서 예외가 발생하면 실제로 발생할 모든 예외가 발생했을 때 실제로 발생하도록 테스트를 작성하십시오.
13. CheckTrue 또는 Assert의 사용을 피하십시오.
부울 조건을 검사하지 마십시오. 예를 들어, 두 객체가 CheckTrue 또는 Assert.IsTrue와 동일한 지 확인하는 대신 CheckEquals 또는 Assert.IsEqual을 대신 사용하십시오. 왜? 이것 때문에:
CheckTrue (Expected, Actual) "Some test failed : Expected는 참이지만 실제 결과는 False입니다."
이 말은 당신에게 아무 것도 말하지 않습니다.
수표 (예상, 실제)
그러면 다음과 같은 내용이 표시됩니다. "일부 테스트가 실패했습니다. 예상되는 7 개이지만 실제 결과는 3 개입니다."
예상 값이 실제로 부울 조건 일 때만 CheckTrue 또는 Assert.IsTrue를 사용하십시오.
14. 끊임없이 테스트를 실행하십시오.
코드를 작성하는 동안 테스트를 실행하십시오. 테스트를 빨리 실행해야하므로 사소한 변경 후에도 실행할 수 있습니다. 일반적인 개발 프로세스의 일부로 테스트를 실행할 수없는 경우 문제가 발생합니다. 단위 테스트는 거의 즉시 실행됩니다. 그렇지 않은 경우, 아마 당신이 그들을 고립되어 운영하지 않기 때문일 것입니다.
15. 모든 자동화 된 빌드의 일부로 테스트를 실행하십시오.
개발하는 동안 테스트를 실행해야하는 것처럼 지속적인 통합 프로세스의 필수 요소가되어야합니다. 실패한 테스트는 빌드가 손상되었음을 의미합니다. 실패한 테스트가 남아 있도록하지 마십시오. 그것을 빌드 실패로 간주하고 즉시 수정하십시오.
C #의 간단한 단위 테스트 예제
이 예제에서는 간단한 계산기의 sum 메서드를 테스트합니다.
이 예에서는 ApplicationToTest라는 응용 프로그램을 테스트합니다. 이 클래스에는 Calc라는 클래스가 있습니다. 이 클래스에는 Sum () 메서드가 있습니다.
Sum () 메서드는 다음과 같습니다.
public void Sum(int a, int b)
{
return a + b;
}
이 메소드를 테스트하는 단위 테스트는 다음과 같습니다.
[Testclass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
//Arrange
ApplicationToTest.Calc ClassCalc = new ApplicationToTest.Calc();
int expectedResult = 5;
//Act
int result = ClassCalc.Sum(2,3);
//Assert
Assert.AreEqual(expectedResult, result);
}
}