부정 행위없이 단위 테스트를 통과하기위한 최소 코드 작성!

TDD를 수행하고 단위 테스트를 작성할 때 테스트중인 "구현"코드의 첫 번째 반복을 작성할 때 "치트"하려는 충동에 어떻게 저항합니까?

예를 들어 :
숫자의 계승을 계산해야합니다. 다음과 같은 단위 테스트 (MSTest 사용)로 시작합니다.

[TestClass]
public class CalculateFactorialTests
{
    [TestMethod]
    public void CalculateFactorial_5_input_returns_120()
    {
        // Arrange
        var myMath = new MyMath();
        // Act
        long output = myMath.CalculateFactorial(5);
        // Assert
        Assert.AreEqual(120, output);
    }
}

이 코드를 실행하면 CalculateFactorial메서드가 존재하지 않기 때문에 실패 합니다. 이제 테스트중인 메소드를 구현하기 위해 코드의 첫 번째 반복을 작성 하여 테스트를 통과하는 데 필요한 최소 코드를 작성합니다 .

문제는 계속해서 다음과 같이 작성하고 싶은 유혹입니다.

public class MyMath
{
    public long CalculateFactorial(long input)
    {
        return 120;
    }
}

이것은 점에서 정확한 기술적 인 정말 하는 데 필요한 최소 코드 특정 테스트 통과를 만들기 는 정말도하지 않기 때문에 A는 "속임수"분명히 비록, (친환경) 을 시도 계승을 계산하는 기능을 수행 할 수 있습니다. 물론, 이제 리팩토링 부분은 실제 구현의 리팩토링이 아닌 "올바른 기능을 작성"하는 연습이되었습니다. 분명히 다른 매개 변수로 테스트를 추가하면 리팩토링이 실패하지만 해당 테스트로 시작해야합니다.

그래서 제 질문은 "테스트를 통과하기 위해 최소 코드를 작성하는 것"과 기능을 유지하면서 실제로 달성하려는 정신에 대한 균형을 어떻게 얻습니까?

완벽하게 합법적입니다. 빨강, 녹색, 리 팩터.

첫 번째 시험에 합격합니다.

새로운 입력으로 두 번째 테스트를 추가하십시오.

이제 녹색으로 빠르게 전환하면 if-else를 추가 할 수 있습니다. 통과하지만 아직 완료되지 않았습니다.

빨강, 초록, 리 팩터의 세 번째 부분이 가장 중요합니다. 중복 제거 리팩터링 . 이제 코드에 중복이 생길 것입니다. 정수를 리턴하는 두 개의 명령문. 그리고 그 중복을 제거하는 유일한 방법은 함수를 올바르게 코딩하는 것입니다.

처음에는 올바르게 쓰지 않는다고 말하는 것이 아닙니다. 당신이하지 않으면 부정 행위가 아니라고 말하는 것입니다.

궁극적 인 목표에 대한 이해와 그 목표를 충족하는 알고리즘의 달성이 필요합니다.

TDD는 디자인의 마법의 총알이 아닙니다. 여전히 코드를 사용하여 문제를 해결하는 방법을 알아야하며, 테스트 통과를 위해 몇 줄의 코드보다 높은 수준에서이를 수행하는 방법을 알아야합니다.

나는 좋은 디자인을 장려하기 때문에 TDD의 아이디어를 좋아한다. 테스트 할 수 있도록 코드를 작성하는 방법을 생각하게하며 일반적으로 철학은 코드를 전체적으로 더 나은 디자인으로 이끌 것입니다. 그러나 여전히 솔루션을 설계하는 방법을 알아야합니다.

테스트를 통과하기 위해 가장 적은 양의 코드를 작성하여 응용 프로그램을 개발할 수 있다고 주장하는 축소주의 TDD 철학을 선호하지 않습니다. 건축에 대해 생각하지 않으면 이것은 작동하지 않으며 귀하의 예는 그것을 증명합니다.

밥 마틴 삼촌 은 이렇게 말합니다.

테스트 주도 개발을 수행하지 않으면 전문가라고 부르기가 매우 어렵습니다. 짐 코 플린 (Jim Coplin)이 카펫에 나를 불렀습니다. 그는 내가 그 말을 좋아하지 않았다. 실제로, 그의 직책은 사람들이 다른 종류의 생각을 포기하기 위해 테스트를 작성하고 미친 듯이 급히 시험을 통과하기 위해 아키텍처를 찢어서 흥미로운 포인트를 얻었 기 때문에 테스트 주도 개발은 아키텍처를 파괴하는 것입니다. 그것은 의식을 남용하고 징계 뒤에 의도를 잃는 흥미로운 방법입니다.

건축을 생각하지 않는다면 건축을 무시하고 테스트를 함께 던지고 통과시키는 것이 건물에 집중하기 때문에 건물을 유지할 수있는 것을 파괴하는 것입니다. 시스템의 구조와 시스템의 구조적 무결성을 유지하는 데 도움이되는 견고한 설계 결정.

단순히 수많은 테스트를 함께 던져 10 년 후 10 년 동안 통과시켜 시스템이 생존 할 것이라고 가정 할 수는 없습니다. 우리는 스스로를 지옥으로 진화시키고 싶지 않습니다. 따라서 좋은 테스트 주도 개발자는 항상 아키텍처 결정을 내릴 때 항상 큰 그림을 생각합니다.

아주 좋은 질문입니다 ... 그리고 @Robert를 제외한 거의 모든 사람들과 동의하지 않아야합니다.

쓰기

return 120;

한 번의 테스트 통과를위한 계승 함수 는 시간 낭비입니다 . 그것은 "속임수"가 아니며 문자 그대로 적 녹색 리 팩터를 따르지 않습니다. 그것은이다 잘못된 .

이유는 다음과 같습니다.

• 계승 계산 은 "상수 반환"이 아닌 피처입니다. "return 120"은 계산 이 아닙니다 .

• '리 팩터'논증은 잘못 인도되었다; 5와 6에 대한 두 가지 테스트 사례가있는 경우 계승 을 전혀 계산하지 않기 때문에이 코드는 여전히 잘못 되었습니다 .

  if (input == 5) { return 120; } //input=5 case
  else { return 720; }   //input=6 case
  

• 문자 그대로 'refactor'인수를 따르는 경우 5 개의 테스트 사례가있을 때 YAGNI를 호출하고 찾아보기 테이블을 사용하여 함수를 구현합니다.

  if (factorialDictionary.Contains(input)) {
      return factorialDictionary[input]; 
  }
  throw new Exception("Input failure");
  

이 중 어느 것도 실제로 아무것도 계산 하지 않습니다 . 그리고 그것은 임무가 아닙니다!

단 하나의 단위 테스트 만 작성한 경우 한 줄 구현 ( return 120;)이 합법적입니다. 120의 값을 계산하는 루프를 작성하면 부정 행위가됩니다!

이러한 간단한 초기 테스트는 에지 사례를 포착하고 일회성 오류를 방지하는 좋은 방법입니다. 실제로 5는 내가 시작할 입력 값이 아닙니다.

여기서 유용 할 수있는 경험 법칙은 0, 1, 많은, 많은 것 입니다. 계승의 중요한 가장자리 사례는 0과 1입니다. 그들은 하나의 라이너로 구현할 수 있습니다. "다수"테스트 사례 (예 : 5!)는 루프를 작성하도록 강제합니다. "lots"(1000 !?) 테스트 사례를 사용하면 매우 많은 수를 처리하는 대체 알고리즘을 구현할 수 있습니다.

테스트가 하나 뿐인 경우 테스트를 통과하는 데 필요한 최소 코드는 실제로 return 120;이므로 더 이상 테스트하지 않는 한 쉽게 유지할 수 있습니다.

이를 통해 실제로이 메소드의 OTHER 리턴 값을 실행하는 테스트를 작성할 때까지 추가 설계를 연기 할 수 있습니다.

테스트는 사양의 실행 가능한 버전이며, 해당 사양 이 모두 f (6) = 120 인 경우 청구서에 완벽하게 맞는다는 것을 기억하십시오.

그러한 방법으로 "속임수"를 할 수 있다면 단위 테스트에 결함이있는 것입니다.

단일 값으로 계승 법을 테스트하는 대신 값의 범위인지 테스트하십시오. 여기에서 데이터 중심 테스트가 도움이 될 수 있습니다.

단위 테스트를 요구 사항의 표현으로 봅니다. 테스트하는 방법의 동작을 집합 적으로 정의해야합니다. (이것은 행동 주도 개발 로 알려져 있습니다 -미래 ;-))

누군가에게 구현을 잘못된 것으로 변경하려는 경우 테스트가 여전히 통과하거나 "일시 중단"이라고 말합니까?

그것을 염두에두고, 유일한 테스트가 귀하의 질문에 대한 테스트라면 기술적으로 해당 구현이 정확합니다. 그런 다음 문제는 잘 정의되지 않은 요구 사항으로 간주됩니다.

더 많은 테스트를 작성하십시오. 결국, 것입니다 짧은 쓰기

public long CalculateFactorial(long input)
{
    return input <= 1 ? 1 : CalculateFactorial(input-1)*input;
}

...보다

public long CalculateFactorial(long input)
{
    switch (input) {
       case 0: return 1;
       case 1: return 1;
       case 2: return 2;
       case 3: return 6;
       case 4: return 24;
       case 5: return 120;
    }
}

:-)

"치트"테스트 작성은 "OK"의 값이 충분히 작 으면 괜찮습니다. 그러나 리콜 장치 테스트는 모든 테스트가 통과 되고 실패 할 새 테스트를 작성할 수없는 경우에만 완료됩니다 . 많은 if 문 (또는 더 나은 큰 switch / case 문 :-) 을 포함하는 CalculateFactorial 메서드를 실제로 원한다면 그렇게 할 수 있으며 고정 소수점 숫자를 처리하기 때문에 필요한 코드 이것을 구현하는 것은 유한합니다 (아마도 크거나 추하고, 아마도 프로 시저 코드의 최대 크기에 대한 컴파일러 또는 시스템 제한에 의해 제한 될 수 있습니다). 이 시점에서 당신이 정말로모든 개발을 단위 테스트로 추진해야한다고 주장하면 if 문의 모든 분기를 따라 수행 할 수있는 것보다 짧은 시간 내에 결과를 계산하는 코드를 요구하는 테스트를 작성할 수 있습니다 .

기본적으로 TDD를 사용하면 요구 사항을 올바르게 구현하는 코드 를 작성할 수 있지만 좋은 코드 를 작성하도록 강요 할 수는 없습니다 . 그것은 당신에게 달려 있습니다.

공유하고 즐기십시오.

나는 Robert Harveys의 제안에 100 % 동의합니다. 테스트를 통과하는 것이 아니라 전반적인 목표를 염두에 두어야합니다.

"지정된 입력 세트로만 작동하는 것으로 확인되었습니다"라는 문제에 대한 해결책으로 xunit 이론과 같은 데이터 기반 테스트를 사용하는 것이 좋습니다. 이 개념의 힘은 출력에 대한 입력 사양을 쉽게 만들 수 있다는 것입니다.

팩토리얼의 경우 테스트는 다음과 같습니다.

    [Theory]
    [InlineData(0, 1)]
    [InlineData( 1, 1 )]
    [InlineData( 2, 2 )]
    [InlineData( 3, 6 )]
    [InlineData( 4, 24 )]
    public void Test_Factorial(int input, int expected)
    {
        int result = Factorial( input );
        Assert.Equal( result, expected);
    }

테스트 데이터 제공 (을 반환 IEnumerable<Tuple<xxx>>)을 구현하고 수학 불변량을 인코딩 할 수 있습니다 ( 예 : n을 반복해서 나누면 n-1이 생성됨).

이 tp는 매우 강력한 테스트 방법입니다.

여전히 속임수를 쓰면 테스트가 충분하지 않습니다. 더 많은 테스트를 작성하십시오! 예를 들어, 입력 1, -1, -1000, 0, 10, 200으로 테스트를 추가하려고합니다.

그럼에도 불구하고, 당신이 정말로 부정 행위를한다면, 끝없는 if-then을 쓸 수 있습니다. 이 경우 코드 검토 외에는 도움이되지 않습니다. 합격 시험에 곧 붙잡 힐 것입니다 ( 다른 사람이 작성했습니다! )

단위 테스트의 문제점은 때때로 프로그래머가이를 불필요한 작업으로 간주한다는 것입니다. 그것들을 보는 올바른 방법은 작업 결과를 올바르게 만드는 도구입니다. 따라서 if-then을 작성하면, 고려해야 할 다른 경우가 있다는 것을 무의식적으로 알고 있습니다. 이것은 다른 테스트를 작성해야 함을 의미합니다. 그리고 부정 행위가 작동하지 않는다는 것을 깨달을 때까지 계속해서 올바른 방식으로 코딩하는 것이 좋습니다. 여전히 완료되지 않았다고 생각되면 완료되지 않은 것입니다.

나는 당신이 선택한 시험이 최선의 시험이 아니라고 제안합니다.

나는 시작합니다 :

첫 번째 검정 인 factorial (1)

두 번째로 계승 (0)

세번째 계승 (-ve)

그리고 사소한 경우로 계속 진행하십시오.

오버플로 사례로 마무리하십시오.