2010-06-28 5 views
5

VB.NET 및 NUnit으로 TDD를 배우고 있습니다. 최선의 방법을 알고 싶습니다. 테스트 메소드 내부에 많은 Assert 메소드를 사용하거나 메소드 당 assert를 사용합니까?VB.NET 및 NUnit - TDD

이것은 내 코드입니다. 고맙습니다.

Imports NUnit.Framework 

<TestFixture()> _ 
Public Class CalculatorTest 
<Test()> _ 
Public Sub TestAdd() 
    Dim calculator As Calculator = New Calculator() 

    Assert.AreEqual(2, calculator.sum(1, 1)) 
    Assert.AreNotEqual(3, calculator.sum(2, 2)) 
    Assert.AreEqual(-1, calculator.sum(0, -1)) 
     Assert.AreNotEqual(3, calculator.sum(1, 1)) 
    End Sub 
End Class 

답변

5

일반적으로 허용되는 '모범 사례'는 테스트 당 하나의 주장입니다.

<Test()> _ 
<TestCase(1, 1, 2)> _ 
<TestCase(1,-1, 0)> _ 
<TestCase(0,-1,-1)> _ 
Public Sub Calculator_Add_ReturnsExpectedResult(Integer a, Integer b, Integer expected) 
    Dim calculator As Calculator = New Calculator() 

    Assert.AreEqual(expected, calculator.sum(a, b)) 
End Class 

이 또한 정확하게 테스트 명확히하기 위해, 내가 거기에 사용되는 명명주의 :

그러나,이 특정 테스트 NUnit를 사용하여 테스트 케이스보다 단순히 조금을 수행 할 수 있습니다 (로이 Osherove에 따르면) 테스트 중입니다.

"One Assert Per Test"연습의 기본 원리는 실패한 테스트가 매우 구체적인 것을 의미하기를 원합니다. 즉, 각 테스트는 하나의 특정 사항이 작동 하는지를 알려야합니다.

+0

_ : 의미는 무엇입니까? 고맙습니다. – Thomas

+0

이것은 테스트 함수를 여러 번 호출 할 것이고, 각기 다른 입력을 갖는다 (주석에 지정된대로). 이 경우에는 (1,1,2)와 (1, -1,0) 그리고 마지막으로 (0, -1, -1)을 사용하여 세 번 호출합니다. –

+0

고마워, 알았다! – Thomas

0

이것은 흥미로운 토론이며 스타일에 달려 있습니다. 저는 Roy Osherove의 견해를 좋아합니다. 단위 테스트 당 하나의 주장 만 있어야합니다.

이 문제에 대한 심도 깊은 토론 here을 읽어보십시오.

또한 this을 확인하십시오.

+0

이것은 실제로 "토론"과 더 많은 스타일 토론이 아닙니다. 각 테스트마다 여러 개의 어설 션을 선호하며, 실제 테스트에서 가장 많이 사용되는 단위 테스트에는 주어진 테스트에 대한 모든 가정을 지우는 데 하나 이상의 어설 션이 필요합니다. –

+0

감사합니다. 나는 그것을 읽겠습니다! – Thomas

7

더 좋은 방법은 한 번에 한 가지씩 테스트하는 것입니다. 한 가지를 테스트하는 데 필요한만큼 많은 어설 션을 사용하지만, 일반적으로 하나만 테스트하십시오. 다중 어설 션은 한 번에 두 가지 이상을 테스트하는 신호가 될 수 있지만 제 생각에는 어렵고 빠른 규칙이 아닙니다. 가장 좋은 지침은 독립적 인 개념간에 테스트에 종속성을 생성하고 싶지 않다는 것입니다.

예를 들어 4 가지 테스트를 실제로하고 있지만 실제로는 동일한 영역을 다루기 때문에 실제로는 2 가지만 필요합니다. 두 개의 양수, 두 개의 음수 및 음수와 양수를 음수 값과 양수 값으로 추가하면 어떻게 될지 테스트해볼 것을 제안합니다. 그렇다면 수학 속성과 테스트 commutativity 및 첨가제 ID (제로)에 대해 생각해 보겠습니다. 마지막으로, 경계 조건을 테스트 할 것입니다 - 양수 및 음수 오버플로, 등등. 이것은 포괄적 일 수도 있고 그렇지 않을 수도 있습니다. 즉, 나는베이스를 다뤘지만, 너무 열심히 시도하지는 않습니다. ; 필자는 테스트 작성 방법에 대해 생각해 보는 방법을 설명하고 싶습니다. 그렇다면이 개별 테스트 각각을 단 하나의 주장만으로 만들 것입니다.

좀 더 복잡한 경우, 동일한 "것을"테스트하는 하나 이상의 어설 션이있을 수 있습니다. 예를 들어 주어진 입력 집합을 사용하여 행이 DB에 제대로 삽입되었는지 확인할 수 있습니다. 각 속성을 개별적으로 테스트하기보다는 모든 열이 단일 테스트에서 적절한 값을 갖고 있는지 테스트하는 것이 완벽하게 받아 들여질 수 있다고 생각합니다. 다른 것은 다를 수 있지만,이 경우 삽입이 원자 적 조치이기 때문에 모든 특성이 올바른 값을 가지고 있는지 테스트하여 종속성을 작성한다고 생각하지 않습니다.

+0

좋은 설명. 고맙습니다! – Thomas

0

Osherove의 근본 주의적 관점. 예를 들어 함수가 구조체/클래스를 반환하면 여러 개의 어설 션을 사용해야하거나 동일한 작업을 실제로 수행하는 어설 션을 비교하는 사용자 지정 구조를 만들 수 있습니다.

중요한 것은 기능이 무엇인지 테스트하는 것입니다. 그리고 항상 "전문가"에게 질문하는 것입니다.