단위 테스트를 작성할 때 테스트 할 사항은 무엇입니까?

Question

이 테스트가 테스트와 좋은 관계를 발전시키는 첫 번째 단계이며 오이와 함께 가장 재미있는 BDD 테스트에 참여할 수 있다고 생각하기 때문에이 테스트를 단위 테스트를 시작하고 싶습니다.

현재 데이터베이스의 모든 테이블을 기반으로하는 Codesmith를 사용하여 모든 Base 클래스를 생성합니다. 이 기본 클래스로 테스트 케이스를 생성하면 얻을 수있는 이점에 대해 궁금합니다. 이 가난한 테스트 관행입니까?

이것은 내 게시물의 궁극적 인 질문으로 이어집니다. 단위 테스트를 사용할 때 우리는 무엇을 테스트합니까?

우리가 원하는 것을 테스트 해 보았습니까? 또는 우리가 원하지 않는 예제를 테스트합니까?

여러 가지 방법으로 실패 할 수 있고 여러 가지 방법으로 성공할 수 있습니다. 언제 중지해야하는지 어떻게 알 수 있습니까?

예를 들어 요약 기능을 사용하십시오. 1,2를주고 단원 테스트에서 3을 기대하십시오. 5,6이 35로 돌아 오지 않는다는 것을 어떻게 알 수 있습니까?

질문의 요점을 되풀이

• 생성 단위 테스트 (좋은/나쁜)
• 무엇을/우리는 얼마나 테스트합니까?

Answer 1

단위 테스트의 요점은 공용 메서드의 실제 동작이 예상되는 동작과 일치한다는 확신을주기위한 것입니다 (그러나 특별한 경우에만 확실성을 부여합니다). 당신이 클래스 Adder

class Adder { public int Add(int x, int y) { return x + y; } } 

및 해당 단위 테스트

[Test] 
public void Add_returns_that_one_plus_two_is_three() { 
    Adder a = new Adder(); 
    int result = a.Add(1, 2); 
    Assert.AreEqual(3, result); 
} 

있는 경우에 따라서, 다음이 당신에게 시험 방법이 적절하게 작동하고 몇 가지 (그러나 100 %) 확신을 제공합니다. 또한 리펙토링시 코드가 깨지는 것을 막을 수 있습니다.

단위 테스트를 사용할 때 무엇을 테스트합니까?

예상되는 (또는 지정된) 동작에 대한 공개 메서드의 실제 동작입니다.

우리가 알고 싶은 예제를 테스트합니까?

예, 메소드의 정확성에 대한 확신을 얻으려면 예상되는 예상 출력을 사용하여 입력에 public 메소드를 실행하고 acutal 출력을 예상 출력과 비교해야합니다.

Answer 2

요구 사항을 시작하고 예상되는 동작을 테스트하는 테스트를 작성하십시오. 이 시점부터, 테스트하는 다른 시나리오는 일정에 따라 결정될 수 있으며, 특히 위험도가 높은 불확실한 시나리오를 인식하여 결정할 수 있습니다.

사용자 또는 사용자가 발견 한 결함 (사용자가 실제로 결함을 수정하기 전에 결함 수정을 테스트하는 테스트를 작성한다는 의미에서 테스트를 수행 할 수 있음)에 대한 응답으로 만 비 성공적인 테스트를 작성할 수 있습니다. 그 결함이 나중에 개발 될 때 코드에 다시 도입되면 실패합니다).

Answer 3

1) 시작하려면 앱 핵심 로직을 테스트 해 보시기 바랍니다.

2) 그런 다음 모든 코드가 테스트에 사용되는지 (if-else의 모든 가지, 대소 문자 조건이 호출되는지) 비교하기 위해 코드 적용 도구를 사용하십시오. 이것은 1 + 2 = 3, 5 + 6 = 35 테스트에 대한 귀하의 질문에 대한 답변입니다. 코드가 적용될 때 추가 실험을 통해 안전하다고 느낄 수 있습니다.

3) 코드 80 ~ 90 %가 커버하는 좋은 습관이다는 : 나머지 작업은 일반적으로 unefficient입니다 : 게터 족, 1 라인 예외 처리 등

4)의 분리에 대해 알아보기 .

5) 생성 단위 테스트 - 직접 작성하는 코드 라인을 절약 할 수 있습니다. 나는 vs로 파일을 생성하는 것을 선호하고 나머지는 TestMethods를 직접 작성한다.

Answer 4

테스트 대상 : 모든 것이 잘못되었습니다.

버그를 찾았 으면 의 버그가있는 동작에 대한 테스트를 작성한 후 코드를 수정하십시오. 그런 다음 코드가 올바르게 작동하면 테스트가 끝나고 다른 테스트가 진행됩니다. 당신이

• 알고리즘은
• 그래서 귀하의 예제에서 훨씬 이해가되지 것입니다 미래

에서의 우발적 인 변경에 대해 보호 할 작동하는지 확인하려면

Answer 5

당신에게 유닛 테스트 일 생성 된 클래스를 테스트합니다. 대신 발전기를 테스트하십시오.

먼저 주요 사용 사례 (테스트 된 기능이 설계된 기능)를 테스트하는 것이 좋습니다. 그런 다음 주요 오류 사례를 테스트합니다. 그런 다음 코너 사례 (예 : 상한 및 하한)에 대한 테스트를 작성합니다. 비정상적인 오류 사례는 일반적으로 생산하기가 너무 어렵 기 때문에 단위 테스트에 의미가 없습니다.

다양한 매개 변수 집합을 확인해야하는 경우 데이터 기반 테스트를 사용하십시오.

테스트 할 물건은 많은 노력과 반품이므로 실제로는 개별 프로젝트에 달려 있습니다. 일반적으로 80/20 규칙을 따르려고 시도하지만 실패로 인해 심각한 결과가 발생할 수 있으므로 더 많은 테스트 커버리지가 필요한 응용 프로그램이있을 수 있습니다.

TDD (Test-Driven Approach)를 사용하는 경우 테스트를 작성하는 데 필요한 시간을 크게 줄일 수 있습니다. 이는 테스트 가능성을 염두에두고 작성된 코드가 훨씬 어렵고 때로는 테스트가 불가능한 경우가 있기 때문입니다. 하지만 인생에서 아무 것도 무료가 아니기 때문에 TDD로 개발 된 코드는 더 복잡 해지는 경향이 있습니다.

Answer 6

또한 단위 테스트를보다 일관되게 사용하기위한 프로세스를 시작했으며 단위 테스트에서 가장 큰 작업은 테스트를 지원하기 위해 코드를 구조화한다는 것입니다.테스트를 작성하는 방법에 대해 생각하기 시작하면서 클래스가 지나치게 결합 된 부분이 명확 해지면서 '단위'의 복잡성으로 인해 정의 테스트가 어려워집니다. 테스트를 작성할 때 코드를 리팩터링하는 데 많은 시간을 소비합니다. 테스트 할 수있는 유닛 간의 경계가 명확 해지면 테스트 시작 위치에 대한 질문이 스스로 해결됩니다. 최소한 고립 된 의존성 (또는 적어도 당신이 걱정하고있는 것들)을 가지고 시작하고 당신의 방법대로 일하십시오.

Answer 7

내가 테스트하는 세 가지 기본적인 이벤트가 있습니다. 분, 최대, 중간에서 최소 사이.

그리고 적절한 경우 두 가지 극단 : 분 미만 및 최대 이상.

명백한 예외가 있습니다 (일부 코드는 최소 또는 최대 예를 들어 있지 않을 수 있습니다). 그러나 이러한 이벤트에 대한 단위 테스트가 좋은 시작이며 코드의 "일반적인"문제의 대부분을 파악합니다.