RSpec : 설명, 컨텍스트, 기능, 시나리오?

describe, context, feature, scenario: 무엇을 사 사이의 차이 (들)이고, 할 때마다 하나를 사용?

는 context별칭입니다 describe그들은 기능적으로 동일하므로,. 서로 바꿔서 사용할 수 있지만 유일한 차이점은 사양 파일을 읽는 방법입니다. 예를 들어 테스트 출력에는 차이가 없습니다. RSpec 책은 다음과 같이 말합니다.

"우리는 describe()사물과 context()맥락 에 사용하는 경향이 있습니다 ."

개인적으로 사용 describe하고 싶지만 사람들이 선호하는 이유를 알 수 있습니다 context.

feature및 scenario카피 바라의 일부, 그리고 RSpec에, 및 수용 테스트에 사용하기위한 것입니다. feature동등 describe/ context및 scenario동등 it/ example.

Capybara로 수락 테스트를 작성하는 경우 feature/ scenario구문을 사용하지 않으면 describe/ it구문을 사용하십시오 .

오늘 아침 몇 가지 사양을 작성하는 동안 동일한 질문이있었습니다. 보통은 주로 사용 describe하고 특별히 생각하지 않지만, 오늘 아침에는 한 모듈에 대해 많은 케이스와 다른 사양을 다루고 있었기 때문에 해당 사양을 읽을 다음 개발자가 쉽게 이해할 수 있어야했습니다. 그래서 구글에 이것에 대해 물었고, 이것을 발견했습니다 : describe vs. context in rspec , 그 대답은 꽤 흥미 롭습니다.

rspec 소스 코드에 따르면 "context"는 "describe"의 별칭 메서드 일 뿐이며, 이는이 두 메서드간에 기능적 차이가 없음을 의미합니다. 그러나 두 가지를 모두 사용하여 테스트를 더 이해하기 쉽게 만드는 데 도움이되는 상황 별 차이가 있습니다.

"설명"의 목적은 하나의 기능에 대해 일련의 테스트를 래핑하는 것이며 "컨텍스트"는 동일한 상태에서 하나의 기능에 대해 일련의 테스트를 래핑하는 것입니다.

따라서이 원칙에 따라 다음과 같은 사양을 작성합니다.

#
# The feature/behaviour I'm currently testing
#
describe "item ordering" do
  
  # 1st state of the feature/behaviour I'm testing
  context "without a order param" do
    ...
  end

  # 2nd state of the feature/behaviour I'm testing
  context "with a given order column" do
    ..
  end

  # Last state of the feature/behaviour I'm testing
  context "with a given order column + reverse" do
    ..
  end
end

이것이 일반적으로 받아 들여지는 규칙인지 확실하지 않지만이 접근 방식은 명확하고 이해하기 쉽습니다.

문서 에 따르면 Pierre의 탁월한 답변을 확장합니다 .

기능 및 시나리오 DSL은 각각 설명 및 그것에 해당합니다. 이러한 메서드는 단순히 기능 사양이 고객 및 승인 테스트로 더 많이 읽을 수 있도록하는 별칭입니다.

따라서 Mocha 용어 설명 및 설명 (사용자 관점에서 테스트 동작을 설명하는 데 더 적합하므로 Mocha는 주로 프런트 엔드 테스트 프레임 워크로 작동 함)에 익숙한 사용자를 위해 다음을 수행 할 수 있습니다.

• 항상 선택할 만 사용 describe하고 it또는 다른 페어링
• 특정 앱 상태에서 여러 개의 어설 션 / 테스트를 수행해야하는 블록 it내부 에서 사용하도록 선택context

두 번째 옵션을 사용하면 "... 동일한 상태에서 하나의 기능에 대한 테스트 세트를 랩핑 (wrap [ping]]) 할 수 있습니다.

따라서 테스트는 다음과 같이 보일 수 있습니다.

#
# The feature/behaviour I'm currently testing
#
describe "item ordering" do

  # 1st state of the feature/behaviour I'm testing
  context "without an order param" do
    # 1st and only test we want to run in this state
    it "asks the user for missing order param" do
     ...
    end
  end

  # 2nd state of the feature/behaviour I'm testing
  context "with an invalid order param" do
    # 1st test we want to run in this state
    it "validates and rejects order param" do
      ...
    end
    # 2nd test we want to run in this state
    it "returns an error to user" do
      ...
    end
  end

  # 3rd state of the feature/behaviour I'm testing with multiple tests
  context "with a valid order param" do
    it "validates and accepts order param" do
      ...
    end
    it "displays correct price for order" do
      ...
    end
    unless being_audited
      it "secretly charges higher price to user" do
        ...
      end
    end
  end
end

이렇게하면 feature 특정 프런트 엔드 기능에 사용하고 싶을 수 키워드를 완전히 거나 FDD (기능 중심 개발)를 수행하는 경우 일부 사용자에게는 불편할 수 있습니다. 여기에서 개발자 팀에 의견을 요청하세요.

주의 사항 : 항상 업계 표준을 따르지는 않습니다. 폭스 바겐 철학을 따라 모든 테스트를 모델링했다고 상상해보십시오.