수용 테스트의 구체적인 예는 무엇입니까?

Question

저는 Gherkin/ATDD/BDD를 처음 사용합니다. 대신 특정 인물을 인용하여, 예를 들어,

Given a user is waiting for an operation to complete 
    And the operation is <percent>% complete 
When <threshold> seconds elapse 
Then a progress indicator should be displayed 
    And the progress indicator should display "<percent>%" 

이 특정 충분히 아니면 내가 (SBE 관점에서 생각하고) 좀 더 구체적인 예를 대표하는 감안할 때 절을 수정해야합니다 : 나는 다음과 같은 수용 테스트를 제도하고있어 진행중인 정확한 "작업"을 인용하는 것 (예 : 고객 목록을 가져 오는 것)?

덕분에, 토니

Answer 1

BDD

행동 기반 개발은 모든 개발 팀과 비즈니스 사이의 대화에 관한 것입니다. 기능 파일과 시나리오는 항상 특정 비즈니스 요구 사항, 기능 또는 기능과 관련이 있어야합니다. 즉, 비즈니스 및 개발 팀이 설명 된 내용을 정확히 이해할 수 있어야합니다.

Feature: Rewards for frequent flyers 
    As a frequent flyer 
    I should receive points to my account 
    So that I am more likely to book with BDD Airlines again in the future 

Scenario: I get flyer miles 
    Given I book a flight 
    And this flight earns 100 miles 
    When I land 
    Then my account should have 100 miles added to it 

이 문제는,이 전체 문제를 간략하게 설명 않습니다 또는 필요한 자세한 내용은이 : 예를 들어

? 개발 팀이이 대화를 사용하여 무언가를 만들 수 있습니까 (SBE에 관해서)?

이

Feature: Rewards for frequent flyers 
    As a frequent flyer 
    I should receive points to my account 
    So that I am more likely to book with BDD Airlines again in the future 

Scenario: Passenger gets flyer miles 
    Given the account number 12341234 has a ticket for the "LGW-MAN" flight 
    And this route earns 100 miles 
    And the ticket is scanned at "LGW" 
    When the flight lands at "MAN" 
    Then the account 12341234 is rewarded 100 miles 

Scenario: Passenger missed their flight 
    Given the account number 12341234 has a ticket for the "LGW-MAN" flight 
    And this route earns 100 miles 
    And the ticket is not scanned at "LGW" 
    When the flight lands at "MAN" 
    Then the account 12341234 is not rewarded any miles 

Scenario: Passenger gets kicked off the plane 
    Given the account number 12341234 has a ticket for the "LGW-MAN" flight 
    And this route earns 100 miles 
    And the ticket is scanned at "LGW" 
    But the ticket is removed from the flight 
    When the flight lands at "MAN" 
    Then the account 12341234 is not rewarded any miles 

그것은 모든 선명도에 대해, 그리고 시스템의 행동이 비즈니스에 관련하여 설명하는 방법에 대한 일반적으로 더 나은? 될 것이다.

귀하의 예

개인적으로 사업이 사용 된 모든 구성 요소의 구현에 관심을 안 등의 진행률 표시 줄을 테스트하기위한 목적으로 시나리오를 작성하지 것이다

(그들은 상관 없어 로딩 바에 관해서는 정보가 실제로로드된다는 사실을주의하십시오.)

제 생각에는 단위 테스트로 더 좋을 것입니다.

Answer 2

예, 더 구체적으로해야한다. 한 가지 유형의 사용자 만 있거나이 테스트 사례가 모든 사용자 그룹 "user"에 적용되는 경우 테스트에 충분할 것입니다. 그러나 TDD는 코드에 대해 안전하다고 느끼기 때문에 모든 작업에 대해 테스트하지 않으면 어디에서나 작동하는지 확인할 수 있기 때문에 기다려야하는 작업을 지정해야한다고 생각합니다. 지연?

Answer 3

진행률 막대는 고저입니다.

심미를 테스트하는 유일한 방법은 사람들에게 보여주고 그들이 생각하는 것을 보는 것입니다. A/B 테스트가 정말 좋습니다. 미학은 실제로 시스템의 원하는 동작에 관한 것이 아니라 사용자의 원하는 동작에 관한 것이기 때문에 BDD는 특히 미학에 적합하지 않습니다..

우리는 여전히 사람들을 효과적으로 프로그래밍하는 방법을 배우고 있습니다. 그때까지는 스크립트가 아닌 인간과 함께 미학을 테스트하십시오.

진행률 표시 줄의 동작 측면에 적합한 알고리즘이 있다면 테스트 가치가있을 것입니다.하지만 다른 사람들이 말했듯이 이는 클래스 수준의 BDD에서 가장 좋은 점입니다. 코드에 직접적으로 묶여있다.

해당 수준에서 "Given, When, Then" statements in comments을 넣으면 충분합니다. 클래스 수준 단계는 시스템 수준 단계와 동일한 방식으로 재사용되지 않으므로 재사용 가능한 추상화로 변경하는 것은 변경하기 쉽지 않은 것처럼 중요하지 않습니다. J/N/WhateverUnit으로 붙잡고 나머지는 조롱하십시오.