BDD 온 레일

TDD를 사용하는 경우 기본적으로 모범 사례 집합인 BDD로 쉽게 시작할 수 있습니다. BDD에는 사양을 작성하는 방법과 테스트할 항목을 알려주는 일련의 간단한 규칙이 있습니다. 사양은 세 부분으로 나뉩니다: 주어진(테스트 조건 설정), 언제(대상에 대한 동작 호출), 그리고 나서(어설션). 테스트는 설명적인 이름을 가져야 하며 기존 테스트 프레임워크는 자연어와 유사한 메서드와 어설션을 사용할 수 있도록 허용하며, 이 모든 것을 결합하면 기술자와 비기술자 모두가 읽을 수 있는 테스트를 만들 수 있습니다. 좋은 이름 지정 규칙은 회귀 테스트 중에 유용합니다.

BDD에는 테스트 대상에 대한 일련의 가이드라인도 함께 제공됩니다. TDD와 달리 테스트 구현에서 테스트 동작으로 초점을 전환하며, 이를 통해 더 나은 설계로 이어지고 변경을 도입해야 할 때 더 많은 유연성을 제공합니다. 사양은 문서화되고 실행 가능한 클라이언트 요구 사항과 같아야 하며, 높은 수준의 사양은 승인 테스트와 같은 역할을 해야 합니다. 목표는 요구 사항이 변경될 때만 변경해야 하는 방식으로 테스트를 작성하는 것입니다. BDD를 사용하면 실제로 다루어야 하는 것을 테스트하고 있다는 확신을 가질 수 있으며 TDD보다 더 실용적인 접근 방식입니다.

BDD가 실제로 작동하는 모습을 보고 싶으시다면 Ruby를 추천합니다. 강력하고 재미있게 사용할 수 있는 언어이며 훌륭한 BDD 도구 세트가 있습니다.

오이

Cucumber는 루비에서 가장 많이 사용되는 BDD 프레임워크입니다. 여기에는 테스트를 작성하는 데 사용되는 Gherkin이라는 특수 언어가 도입되어 있습니다. RSpec과 달리 Gherkin에서 설명하는 기능은 일반 텍스트가 아닌 코드따라서 누구나, 특히 클라이언트가 이해할 수 있고 이해해야 합니다.

오이 기능은 다음과 같습니다(오이 위키에서 가져온 예제):

 기능: 원하는 기능에 대한 간결하면서도 설명적인 텍스트
    이 기능의 비즈니스 가치에 대한 텍스트 설명
    기능의 범위를 관리하는 비즈니스 규칙
    기능을 더 쉽게 이해할 수 있는 추가 정보

  시나리오 결정 가능한 비즈니스 상황
    몇 가지 전제 조건이 주어짐
    그리고 다른 전제 조건
    배우가 어떤 행동을 했을 때
    그리고 다른 행동
    그리고 또 다른 행동
    그런 다음 테스트 가능한 결과가 달성됩니다.
    그리고 우리가 확인할 수 있는 다른 무언가도 일어납니다.

  시나리오: 다른 상황
    ...

기능에 대해서는 나중에 자세히 설명하겠습니다.

Ruby on Rails에서 오이 사용

설치

Cucumber를 사용하기 위한 첫 번째 단계 프로젝트 를 설치하는 것입니다. 이 두 가지 젬을 젬파일에 추가하기만 하면 됩니다:

그룹 :테스트하다
  gem 'cucumber-rails', :require => false
  gem '데이터베이스_클리너'
end

다음을 실행하여 번들링합니다. 번들 설치를 클릭하고 다음 명령으로 Cucumber 스크립트와 디렉터리를 생성합니다:

레일 생성 오이:설치

이렇게 하면 다음이 생성됩니다. config/cucumber.yml, 스크립트/오이 그리고 기능/ 디렉토리여기에는 다음이 포함됩니다. .feature 파일은 물론 단계 정의 및 지원 파일도 포함합니다. 기능을 실행하려면 새 레이크 명령을 사용하세요:

오이 갈퀴

특징

기능에 대해 자세히 살펴봅시다. 기능은 주기적으로 뉴스레터를 보내거나 사용자가 자신의 사진을 공개적으로 공유할 수 있도록 하는 등 애플리케이션이 가지고 있거나 수행하는 기능입니다. 하나의 기능은 여러 시나리오로 구성되며, 시나리오는 이 기능이 다양한 상황에서 어떻게 작동하는지 설명합니다.

Rails에서 Cucumber의 기본 사용법을 보여드리기 위해 기능을 처음부터 작성해 보겠습니다. 이 예제 기능은 애플리케이션에서 작성하는 첫 번째 기능이 될 것이며, 이 글의 다음 두 번째 파트에서 보여드리겠습니다. 이 애플리케이션을 통해 사용자는 아이템과 상점(상점에서는 아이템을 판매)을 만든 다음 쇼핑 목록을 만들 수 있습니다.

가장 간단한 버전에서는 쇼핑 목록을 컴파일한 후 사용자가 원하는 품목이 가장 저렴한 상점을 애플리케이션에 표시합니다.

먼저, 다음과 같은 이름의 새 파일을 만듭니다. create_item.feature 에서 features/ 디렉터리에 추가합니다. 디렉터리 상단의 .feature 파일에 기능 키워드를 입력한 다음 해당 키워드에 대한 간단한 설명을 입력합니다. 예를 들어

기능: 항목 만들기

다음 줄에 이 기능을 구현할 비즈니스 목표를 작성할 수 있습니다. Cucumber는 첫 번째 시나리오 이전에 작성된 텍스트를 무시하므로 아무것도 작성할 필요는 없지만 확실히 좋은 아이디어입니다.

   주변 상점에서 판매되는 품목으로 쇼핑 목록을 쉽게 생성하기 위해
   사용자로서
   시스템에 아이템을 추가하고 싶습니다.

위의 스니펫에서 비즈니스 목표를 설명할 수 있는 꽤 인기 있는 패턴을 볼 수 있습니다. 이 패턴은 기능이 필요한 이유, 누가 원하는 기능, 기능의 내용 등 세 부분으로 구성됩니다. 물론 이 형식을 따를 필요는 없지만 설명에 이 세 가지 질문에 대한 답변을 반드시 포함하세요.

시나리오

다음으로 몇 가지 시나리오를 작성합니다. 각 시나리오는 "시나리오"라는 키워드로 시작하며 여러 단계로 구성되어 있습니다.

    시나리오: 고유 아이템 만들기
      "우유" 아이템이 있다고 가정합니다.
      메인 페이지로 이동합니다.
      그리고 "빵" 아이템을 생성합니다.
      그러면 아이템 목록에 "빵"이 표시됩니다. 

따라서 누군가 우유라는 이름의 아이템을 생성했다면 빵을 생성할 수 있고 아이템 목록에 빵이 표시됩니다. 이 사실은 고객에게 실질적인 가치가 없으므로 데이터베이스에 레코드가 생성되었는지 테스트해서는 안 됩니다.

시나리오의 단계는 세 가지 주요 키워드를 사용합니다:

• 주어진를 사용하여 시나리오에 컨텍스트를 제공합니다.
• 언제를 사용하여 작업을 설명합니다.
• 그런 다음를 사용하여 결과를 설명합니다.

한 가지 중요한 점은 Cucumber는 시작하는 키워드 단계를 무시하고 뒷부분만 일치시킨다는 점입니다. 따라서 자연스럽게 느껴지는 곳이면 어디에서나 "그리고"로 단계를 시작할 수 있습니다. 올바른 키워드를 선택하는 유일한 규칙은 시나리오를 쉽게 이해할 수 있어야 한다는 것입니다.

단계 정의

이제 Cucumber를 실행하면 이 출력이 생성됩니다:

[...]
기능: 아이템 생성
  주변 상점에서 판매되는 아이템으로 쇼핑 목록을 쉽게 생성할 수 있습니다.
  사용자로서
  시스템에 아이템을 추가하고 싶습니다.

  시나리오: 고유 아이템 생성 # features/create_item.feature:6
    "우유" 아이템이 있다고 가정했을 때 # features/create_item.feature:7
      정의되지 않은 단계: ""우유" 아이템이 있습니다"(오이::정의되지 않음)
[...]

이는 "우유 항목이 있습니다"라고 말할 때 Cucumber가 무슨 뜻인지 모르기 때문입니다. 단계에 의미를 추가하려면 다음에서 단계를 정의해야 합니다. 단계_정의 디렉터리로 이동합니다.

단계 정의를 정리하는 권장 방법은 도메인별로 나누는 것입니다. 예를 들어, 우리가 만든 대부분의 단계는 Item 도메인에 속합니다. 따라서 다음과 같은 이름의 파일을 만들어야 합니다. step_definitions/item_steps.rb 를 클릭하고 다음 코드를 입력합니다:

"$name" 항목이 있다"가 주어지면 |name|을 수행합니다.
  제작 : 항목, 이름 : 이름
end

""$name" Item을 생성"할 때 |name|을 수행합니다.
  "#new_item" 내에서 다음을 수행합니다.
    fill_in "이름", with: 이름
    클릭_온 "생성"
  end
end

그런 다음 "항목 목록에 "$name"이 표시됩니다." do |name|
  ".items" 내에서
    expect(page).to_content name
  end
end

단계 정의는 일반적으로 Capybara를 기준으로 합니다. Capybara에 익숙하지 않다면 이 문서 끝에 있는 링크를 확인하세요.

정의가 필요한 단계가 하나 더 있는데 항목 단계에는 적합하지 않습니다. 이 단계를 메인_페이지_스텝.rb:

"메인 페이지로 이동"하면 다음과 같이 하세요.
  방문 루트 경로
끝

결론

이것은 아주 간단한 기능에 대한 아주 간단한 이야기입니다. 이 스토리의 목적은 Cucumber에서 사용되는 BDD의 핵심 개념을 보여주기 위한 것이었습니다. 하지만 좋은 스토리를 작성하려면 조금 더 많은 것이 필요합니다. 개발자로서 사고방식을 완전히 바꿔야 합니다. 구현은 잊어버리고 대신 비즈니스 목표에 집중해야 합니다. Cucumber는 일반 텍스트 스토리를 영리하게 사용하여 이러한 전환을 더 쉽게 만들어 줍니다.

출처, 영감, 흥미로운 읽을거리:

• https://github.com/cucumber/cucumber/wiki/Cucumber-Backgrounder
• https://github.com/jnicklas/capybara
• https://blog.engineyard.com/2009/15-expert-tips-for-using-cucumber
• http://blog.codeship.com/cucumber-best-practices/
• http://www.elabs.se/blog/15-you-re-cuking-it-wrong
• https://github.com/strongqa/howitzer/wiki/Cucumber-Best-Practices