Yahtzee 게임 TDD 스타일을 작성한다고 가정 해 봅시다. 5 개의 다이 롤 세트가 풀 하우스인지 여부를 판별하는 코드 부분을 테스트하려고합니다. 내가 아는 한, TDD를 수행 할 때 다음 원칙을 따르십시오.
- 먼저 테스트를 작성하십시오
- 가능한 가장 간단한 것을 작성하십시오
- 세분화 및 리팩터링
따라서 초기 테스트는 다음과 같습니다.
public void Returns_true_when_roll_is_full_house()
{
FullHouseTester sut = new FullHouseTester();
var actual = sut.IsFullHouse(1, 1, 1, 2, 2);
Assert.IsTrue(actual);
}
"가장 간단한 것을 작성하십시오"를 따르면, 다음 IsFullHouse과 같이 메소드를 작성해야 합니다.
public bool IsFullHouse(int roll1, int roll2, int roll3, int roll4, int roll5)
{
if (roll1 == 1 && roll2 == 1 && roll3 == 1 && roll4 == 2 && roll5 == 2)
{
return true;
}
return false;
}
이로 인해 친환경 테스트가 이루어 지지만 구현이 불완전합니다.
전체 주택에 대해 가능한 모든 유효한 조합 (값과 위치 모두)을 단위 테스트해야합니까? 그것은 IsFullHouse코드가 완전히 테스트되고 정확 하다는 것을 절대적으로 확신하는 유일한 방법처럼 보이지만 그렇게하는 것은 미친 듯이 들립니다.
이런 식으로 어떻게 단위 테스트를 하시겠습니까?
최신 정보
Erik과 Kilian은 초기 구현에서 리터럴을 사용하여 친환경 테스트를받는 것이 가장 좋은 방법은 아니라고 지적합니다. 왜 그런 짓을했는지 설명하고 싶습니다. 그 설명은 주석에 맞지 않습니다.
단위 테스트 (특히 TDD 접근 방식 사용)에 대한 나의 실제 경험은 매우 제한적입니다. 나는 Tekpub에서 Roy Osherove의 TDD 마스터 클래스를 녹화 한 것을 본 적이 있습니다. 에피소드 중 하나에서 그는 문자열 계산기 TDD 스타일을 만듭니다. 문자열 계산기의 전체 사양은 여기에서 찾을 수 있습니다 : http://osherove.com/tdd-kata-1/
그는 다음과 같은 테스트로 시작합니다.
public void Add_with_empty_string_should_return_zero()
{
StringCalculator sut = new StringCalculator();
int result = sut.Add("");
Assert.AreEqual(0, result);
}
이 Add방법의 첫 번째 구현 결과는 다음과 같습니다.
public int Add(string input)
{
return 0;
}
그런 다음이 테스트가 추가됩니다.
public void Add_with_one_number_string_should_return_number()
{
StringCalculator sut = new StringCalculator();
int result = sut.Add("1");
Assert.AreEqual(1, result);
}
그리고 Add방법은 리팩토링됩니다.
public int Add(string input)
{
if (input.Length == 0)
{
return 0;
}
return 1;
}
각 단계 후에 Roy는 "작동하는 가장 간단한 것을 작성하십시오"라고 말합니다.
그래서 나는 TDD 스타일의 Yahtzee 게임을 할 때이 접근법을 시도해 볼 것이라고 생각했습니다.
if (roll1 == 1 && roll2 == 1 && roll3 == 1 && roll4 == 2 && roll5 == 2)