BDD를 사용할 때 단위 테스트를 사용하는 방법은 무엇입니까?

BDD를 이해하려고합니다. 일부 기사를 읽었으며 BDD가 TDD의 "다음 단계"라는 것을 이해했습니다. 나는 두 가지가 매우 비슷하다는 것을 알았 기 때문에이 기사 에서 읽을 수 있듯이 BDD는 TDD의 개선으로 태어났습니다. 좋아, 나는 그 아이디어를 정말로 좋아한다.

내가 얻지 못하는 한 가지 실용적인 점이 있다고 생각합니다 .BA가 시스템이 가질 것으로 예상되는 모든 동작을 기록하는 .feature 파일이 있습니다. BA로서 그는 시스템이 어떻게 구축되는지 전혀 모릅니다. 그래서 우리는 다음과 같이 작성할 것입니다 :

+ 시나리오 1 : 계정이 신용 상태입니다 +

계정이 신용 상태 인 경우

그리고 카드는 유효합니다

디스펜서에는 현금이 들어 있습니다

고객이 현금을 요청할 때

그런 다음 계정에서 인출되고 현금이 인출되는지 확인하십시오.

그리고 카드가 반환되었는지 확인하십시오

좋아, 이것은 훌륭하지만, 협력 할 시스템의 많은 부분이있다 (계정 obj, 디스펜서 obj, 고객 obj 등). 나에게 이것은 통합 테스트처럼 보입니다.

단위 테스트를하고 싶습니다. 디스펜서에 돈이 있는지 확인하는 코드를 어떻게 테스트합니까? 아니면 현금이 분배됩니까? 아니면 필요할 때 계좌에서 인출됩니까? "BA Created"테스트와 단위 테스트를 어떻게 혼합 할 수 있습니까?

행동 주도 개발 및 테스트 주도 개발은 무료이지만 서로를 대체하지는 않습니다.

응용 프로그램의 작동 방식은 승인 테스트에 설명되어 있으며 BDD에 따르면 오이로 작성된 기능 및 시나리오가 될 것입니다.

각 작은 구성 요소의 작동 방식에 대한 자세한 내용은 단위 테스트에 설명되어 있습니다. Unit Tests의 결과는 오이에 쓰는 시나리오를 지원합니다.

자동차를 만드는 과정을 상상해보십시오.

먼저, 제품 팀은 아이디어를 도출하고 결국 사용 시나리오로 요약합니다.

Scenario: Starting the car
    Given I am standing in front of the drivers door
    When I open the door
    Then the door should lift up DeLorean-style (yeah, baby!)
    When I get into the car
    And turn the key
    Then the engine roars to life

이 시나리오는 약간 어리석은 것으로 알고 있지만 매우 높은 수준의 제품 및 최종 사용자 중심 요구 사항입니다. 도어를 열고 열쇠를 돌리고 엔진을 시동하기 만하면 수많은 부품이 함께 작동합니다. 이 하나의 테스트만으로는 차량이 제대로 작동하는지 확인할 수 없습니다. 시동기, 배터리, 발전기, 키, 점화 스위치를 테스트해야하며 목록이 계속 켜져 있습니다. 차에 타서 시동하십시오. 이러한 각 구성 요소에는 자체 테스트가 필요합니다.

위의 시나리오는 "큰 그림"테스트입니다. 차량의 각 구성 요소는 전체에서 제대로 작동하는지 확인하기 위해 "작은 그림"테스트가 필요합니다.

소프트웨어 구축 및 테스트는 여러 측면에서 동일합니다. 위에서 아래로 디자인 한 다음 아래에서 위로 빌드합니다. 엔진을 시동 할 수 없는데 왜 문이 올라가는가? 배터리가 없으면 왜 시동기가 있습니까?

제품 팀이 수락 테스트를 작성하여 오이에서 육체를 만들 것입니다. 이것은 당신에게 "큰 그림"을 제공합니다. 이제 적절한 구성 요소를 설계하고 상호 작용하는 방법을 엔지니어링 팀이 결정하고 각 구성 요소를 개별적으로 테스트해야합니다. 이것이 바로 단위 테스트입니다.

단위 테스트가 통과되면 오이 시나리오 구현을 시작하십시오. 일단 통과하면 제품 팀이 요청한 내용을 전달한 것입니다.

BDD를 이해하려고합니다. 일부 기사를 읽었으며 BDD가 TDD의 "다음 단계"라는 것을 이해했습니다. 나는 둘 다 매우 비슷하다는 것을 알기 때문에이 기사에서 읽을 수 있듯이 BDD는 TDD의 개선으로 태어났습니다.

실제로, BDD는 TDD의 "다음 단계" 가 아닙니다 . 그것은 이다 TDD. 보다 정확하게는 TDD의 표현입니다.

BDD의 제작자들은 TDD가 테스트에 관한 것이 아니라 행동 명세에 관한 것임을 이해하는 데있어 주요 장애물은 모든 TDD 용어가 행동 명세에 관한 것이 아니라 테스트에 관한 것이라는 점을 알아 차 렸습니다. 누군가가 "핑크 코끼리를 생각하지 마십시오"라고 말하면 분홍색 코끼리를 생각하지 않는 것과 같습니다. 분홍색 코끼리로 가득 찬 방에있는 추가 합병증과 "분홍색 코끼리, 분홍색을 끊임없이 부르는 사람" 코끼리, 분홍색 코끼리 "귀에.

그래서 그들은 행동 규범 측면에서 TDD를 표현했습니다. "테스트"및 "테스트 사례"는 이제 "예", "단위"는 "행동", "어설 션"은 "예상"등입니다.

그러나 방법론은 여전히 ​​동일합니다. 수락 테스트 ( "기능"을 의미 함) 로 시작 하고, 단위 테스트 ( "예"를 의미 함)로 확대하고, 축소하는 등의 작업을 수행합니다.

단위 테스트를하고 싶습니다. 디스펜서에 돈이 있는지 확인하는 코드를 어떻게 테스트합니까? 아니면 현금이 분배됩니까? 아니면 필요할 때 계좌에서 인출됩니까? "BA Created"테스트와 단위 테스트를 어떻게 혼합 할 수 있습니까?

TDD에서와 같은 방법입니다. 기능 및 예제를 다른 프레임 워크 (예 : Cucumber 및 RSpec) 또는 다른 언어 (예 : C로 C 프로젝트에 대한 예제 작성 및 FIT / Fitnesse에서 기능 작성)로 작성할 수 있습니다. 예를 들어 Cucumber에서 예제 및 기능 작성) 또는 둘 다에 대해 단일 예제 프레임 워크를 사용할 수 있습니다 (예 : RSpec에서 둘 다 작성). 프레임 워크를 전혀 사용할 필요조차 없습니다.

단일 프레임 워크를 사용하는 TDD 수행 권한 (BDD와 동일)의 예는 JUnit 자체이며, 여기에는 JUnit 자체로 작성된 단위 테스트 (예)와 기능 / 통합 테스트 (기능)가 혼합되어 있습니다.

켄트 벡 (Kent Beck)은 이것을 "확대"라고 믿습니다. 높은 수준으로 시작한 다음 세부 정보로 "확대"한 다음 다시 되돌립니다.

면책 조항 : 저는 BDD의 전문가는 아니지만 링크 된 기사에 대한 견해를 제시하려고합니다.

TDD는 구현 기술입니다. 먼저 테스트를 작성한 다음 메소드를 구현하고 테스트를 실행하고 리팩토링 한 후 동일한 메소드 또는 새 메소드에 대한 추가 테스트를 추가하십시오. TDD는 실제로 클래스 또는 메소드 이름을 선택하는 방법에 대한 규칙을 정의하지 않습니다. TDD는 또한 "완료되면"말하지 않습니다.

따라서 새로운 분석법에 대한 테스트를 작성할 때마다 분석법 이름을 선택해야합니다. 즉, BDD가 시작되는 지점입니다. 위 시나리오에서 비즈니스 용어를 사용하여 분석법 이름을 선택하고 설명하는 방식으로 분석법 이름을 선택하여 분석법 이름을 선택해야합니다. 수업의 행동, 당신은 BDD를하고 있습니다. "추가 테스트를 추가해야합니까?"라고 물을 때마다 BA에서 제공 한 시나리오를보고 필요한 부분을 모두 구현했는지 확인할 수 있습니다. 그렇지 않은 경우 더 많은 테스트를 추가해야합니다.

이 기사의 저자는 또한 테스트 이름을 선택할 때 더 많은 행동 관련 명명 체계를 사용하도록 제안합니다. 따라서 JUnit을 각 테스트 사례로 시작해야하는 명명 체계에 의존하지 않는 도구로 대체 할 것을 제안합니다. 이름은 "test"입니다. JBehave는 모르지만 이것이 도구와 Junit의 주요 차이점이라고 생각합니다.

당신은 일반적으로 추가 할 것이다 - 또한, BDD 시나리오는 통합 테스트를위한 청사진이 될 것입니다 후 당신은 단위 테스트의 합리적인 금액을 추가 한 후 TDD에 의한 방법 이름을 구체화하고.

제 이해에 따르면 TDD는 BDD의 일부로 사용할 수있는 도구이며 BDD는 올바른 테스트를 작성하고 더 나은 이름을 제공하도록 도와줍니다.