내가 보는 방식에 따라 두 가지 모두 장점이 있으며 “불이익”(sic)에 있습니다.

장점은 편안하다고 느끼고 자신에게 맞는 시스템을 가지고 있다는 것입니다. 제품의 유효성을 확인하게되어 기쁩니다. 다른 프레임 워크를 사용하는 제품에 대해 모든 테스트를 변경하려고하면 비즈니스 가치가 없을 것입니다. 코드를 리팩터링 할 수 있고 테스트에서 변경 사항을 적용하는 경우 또는 테스트를 수정할 수 있고 기존 코드가 리팩터링 될 때까지 테스트에 실패하면 모든베이스를 다룰 수 있습니다. 하나…

잘 설계된 단위 테스트 API를 사용하는 것의 장점 중 하나는 대부분의 최신 IDE에서 많은 기본 지원이 있다는 것입니다. 이것은 Visual Studio 사용자를 비웃는 하드 코어 VI 및 emacs 사용자에게는 영향을 미치지 않지만, 훌륭한 IDE를 사용하는 사용자에게는 테스트를 디버깅하고 실행할 수 있습니다 IDE 자체. 이것은 좋지만 사용하는 프레임 워크에 따라 더 큰 이점이 있으며 코드를 테스트하는 데 사용되는 언어 입니다.

language 라고 말할 때 나는 프로그래밍 언어에 대해 말하는 것이 아니라 테스트 코드를 이야기처럼 읽을 수 있도록 유창한 구문으로 묶인 풍부한 세트 단어에 대해 이야기하고 있습니다. 특히 저는 BDD 프레임 워크 사용을 옹호했습니다 . 내가 가장 좋아하는 DotNet BDD API는 StoryQ입니다.그러나 동일한 기본 목적을 가진 여러 가지가 있습니다. 요구 사항 문서에서 개념을 가져 와서 스펙에서 작성되는 방식과 유사한 방식으로 코드로 작성하는 것입니다. 그러나 테스트에서 모든 개별 명령문을 인터셉트하고 해당 명령문이 성공적으로 실행되었는지 또는 실패했는지를 표시함으로써 실제로 좋은 API가 더욱 발전합니다. 일찍 반환하지 않고 전체 테스트가 실행되는 것을 볼 때 매우 유용합니다. 즉, 전체 호출을 디코딩하지 않고도 실패한 테스트 부분에만주의를 기울여야하기 때문에 디버깅 노력이 매우 효율적입니다. 순서. 다른 좋은 점은 테스트 결과에이 모든 정보가 표시된다는 것입니다.

내가 말하는 것에 대한 예로서, 다음을 비교하십시오.

어설 션 사용 :

Assert(variable_A == expected_value_1); // if this fails...
Assert(variable_B == expected_value_2); // ...this will not execute
Assert(variable_C == expected_value_3); // ...and nor will this!

유창한 BDD API 사용 :
(이탤릭체 비트가 기본적으로 메소드 포인터라고 가정하십시오)

WithScenario("Test Scenario")
    .Given(*AConfiguration*) // each method
    .When(*MyMethodToTestIsCalledWith*, variable_A, variable_B, variable_C) // in the
    .Then(*ExpectVariableAEquals*, expected_value_1) // Scenario will
        .And(*ExpectVariableBEquals*, expected_value_2) // indicate if it has
        .And(*ExpectVariableCEquals*, expected_value_3) // passed or failed execution.
    .Execute();

이제 BDD 구문이 더 길고 더 예리하다는 점을 인정하고 이러한 예제는 끔찍하게 고안되었지만 주어진 시스템 동작의 결과로 시스템에서 많은 것들이 변화하는 매우 복잡한 테스트 상황의 경우 BDD 구문은 명확한 것을 제공합니다. 테스트 대상에 대한 설명 및 테스트 구성을 정의한 방법에 대해 설명하고이 코드를 프로그래머가 아닌 사람에게 보여 주면 진행 상황을 즉시 이해할 수 있습니다. 또한 “variable_A”가 두 경우 모두 테스트에 실패하면 Asserts 예제는 문제를 해결하기 전까지 첫 번째 assert를 지나서 실행되지 않지만 BDD API는 체인에서 호출 된 모든 메소드를 차례로 실행하여 성명서의 개별 부분이 잘못되었습니다.

개인적으로이 접근법은 전통적인 xUnit 프레임 워크가 테스트 언어가 고객의 논리적 요구 사항과 동일한 언어라는 점에서 훨씬 더 효과적이라는 것을 알았습니다. 그럼에도 불구하고 필자는 노력을 지원하기 위해 완전한 테스트 API를 만들지 않고도 비슷한 스타일로 xUnit 프레임 워크를 사용할 수 있었으며 어설 션은 여전히 ​​효과적으로 자체적으로 단락되지만 더 깨끗하게 읽습니다. 예를 들어 :

Nunit 사용 :

[Test]
void TestMyMethod()
{
    const int theExpectedValue = someValue;

    GivenASetupToTestMyMethod();

    var theActualValue = WhenIExecuteMyMethodToTest();

    Assert.That(theActualValue, Is.EqualTo(theExpectedValue)); // nice, but it's not BDD
}

단위 테스트 API를 사용하여 탐색하기로 결정한 경우 잠시 동안 수많은 다른 API를 실험하고 접근 방식에 대해 염두에 두어야합니다. 개인적으로 BDD를 옹호하지만 귀하의 비즈니스 요구에 따라 팀의 상황에 따라 다른 것이 필요할 수 있습니다. 그러나 핵심은 기존 시스템을 추측하지 않는 것입니다. 필요한 경우 다른 API를 사용하여 몇 가지 테스트로 기존 테스트를 항상 지원할 수 있지만 모든 것을 동일하게 만들기 위해 큰 테스트 다시 작성을 권장하지는 않습니다. 레거시 코드의 사용이 중단되면 코드와 해당 테스트를 새로운 코드로 쉽게 대체하고 대체 API를 사용하여 테스트 할 수 있으며 이는 실질적인 비즈니스 가치를 제공 할 필요가없는 큰 노력에 투자 할 필요없이 수행 할 수 있습니다. 단위 테스트 API를 사용하는 경우

답변