RSpec vs Cucumber (RSpec 스토리) [닫기]


136

Rails 애플리케이션에 언제 스펙을 사용해야하고 Cucumber (이전 rspec 스토리)에 언제 사용해야합니까? 물론 사양이 어떻게 작동하고 적극적으로 사용하는지 알고 있습니다. 그러나 오이를 사용하는 것은 여전히 ​​이상합니다. 이것에 대한 나의 현재 견해는 클라이언트를 위해 응용 프로그램을 구현할 때 Cucumber를 사용하는 것이 편리하고 전체 시스템이 아직 어떻게 작동하는지 이해하지 못한다는 것입니다.

하지만 내 자신의 프로젝트를 수행하면 어떻게됩니까? 대부분의 경우 시스템의 일부가 어떻게 상호 작용하는지 알고 있습니다. 내가해야 할 모든 단위 테스트를 작성하는 것입니다. 오이가 필요할 때 가능한 상황은 무엇입니까?

그리고 두 번째 질문으로 오이 이야기를 쓰려면 사양을 작성해야합니까? 같은 것을 두 번 테스트하지 않습니까?


12
올 어떻게 모든 단일 I가 건너 여러 번 빌 도마뱀에 의해 AND 질문 upvoted과 동시에 "건설하지"로 닫혀 있는지 [마감] 질문!?! 내가 뭘 놓치고 있니?
Ashkan Kh. Nazary

4
전적으로 동의합니다. "XXX를 수행하는 가장 좋은 방법"과 같은 질문을 게시 할 위치가 여전히 혼란 스럽습니다.
Dean

3
나는 한 가지 다른 이유로 닫힌 SO에 대한 통찰력 있고 도움이되는 답변으로 좋은 질문을 접한다는 데 동의합니다.
Russell Silva

나는 2017 년 에이 질문을 찾았습니다. 왜냐하면 여전히 관련이 있고 여전히 좋은 질문이며 훌륭한 답변이 있기 때문입니다. 또한 문제의 프레임 워크는 거의 동일한 두 사람이 완전히 분리 된 두 가지 관심사를 위해 설계되었으므로 의견을 불러 일으키지 않습니다. 그러나이를 이해하려면 약간의 전문 지식이 필요합니다.
Lunivore

답변:


114

아직 기사를 작성하지 않았다면 Dan North의 훌륭한 기사 인 What in a Story?를 확인하십시오. 출발점으로.

오이 이야기에는 두 가지 주요 용도가 있습니다. 첫째, 스토리 형식이 매우 구체적이기 때문에 제품 소유자가 원하는 기능을 명확하게 설명하는 데 도움이됩니다. 이것은 이야기의 "대화를위한 토큰"사용이며, 우리가 이야기를 코드로 구현했는지의 여부는 중요합니다. 둘째, 프로세스가 제대로 작동 하여 기능을 작성 하기 전에 완전한 이야기 할 수있을 때 (매일 현실보다 더 이상 노력하는 것이 이상적임) 수용 기준을 명확하게 설명하고 정확히 무엇과 방법을 정확히 알고 있습니다. 많이 만들었습니다.

Rails 작업에서 Cucumber 스토리는 rspec 단위 테스트를 대체하지 않습니다. 두 사람은 손을 잡고 간다. 실제로, 단위 테스트는 모델 및 컨트롤러의 개발을 주도하는 경향이 있으며 스토리는 뷰의 개발을 주도하는 경향이 있으며 (우리는 뷰에 대한 rspec을 작성하지 않는 경향이 있음) 애플리케이션에서 전체적으로 애플리케이션에 대한 훌륭한 테스트를 제공합니다. 사용자의 관점.

혼자 일하고 있다면 의사 소통 측면이 그리 흥미롭지는 않지만 Cucumber에서 얻은 통합 테스트는 그럴 수도 있습니다. webrat 을 활용하면 Cucumber 를 작성하는 것이 많은 기본 기능에 대해 빠르고 고통스럽지 않을 수 있습니다.


6
당신은 두 가지 별개의 문제를 혼동하고 있습니다; 1) 통합 및 승인 테스트를 수행하는 것이 좋으며 2) 오이는 이러한 테스트를 작성하는 데 유용한 도구입니다. 1-예, 분명히 좋은 생각입니다. 2의 경우 rspec과 capybara에서 매우 읽기 쉬운 통합 및 승인 테스트를 작성할 수있을 때 개발 팀이 간접적으로 많은 언어로 테스트를 작성하는 것이 더 효율적이지는 않습니다. / 단위 또는 최소, capybara와 함께). Jack Kinsella가 아래에 링크 한 게시물을 참조하십시오.
Graham Ashton

당신과 완전히 동의합니다 Abie! 오이 통합이 중요합니다!
dpapadopoulos

26

주기로 생각하십시오.

Cucumber 기능을 작성한 다음 해당 기능을위한 조각을 개발하는 동안 개별 구성 요소를 완성하기위한 사양을 작성하십시오. 기능이 전달하기에 충분한 기능을 작성할 때까지 계속 스펙을 작성한 후 다음 기능을 작성하십시오.


1
BDD 외부 사이클의 좋은 예가 있습니다.
rdamborsky 2014

21

제 생각에는 구문에 따라 발생하는 생산성 비용으로 인해 대부분의 상황에서 Cucumber를 사용하는 것이 좋지 않습니다. 나는 왜 오이 테스트로 귀찮게합니까? 에 관한 주제에 대해 광범위하게 썼습니다 .


1
나는 당신의 기사를 읽고 오이의 팬으로서, 당신이 당신의 기사에서 인용하는 많은 점에 동의한다고 말해야합니다. 그래도 오이는 테스트를 공식화하고 외부인이 쉽게 읽을 수 있도록하는 좋은 방법이라고 생각합니다.
포옹

1
잭-환상적인 포스트. 작성해 주셔서 감사합니다. 직접 작성하는 데 따르는 어려움을 덜었습니다.
Graham Ashton

3
huug-테스트를 ​​"외부인"에게 노출시키는 좋은 방법 일 수 있지만 테스트를 읽고 싶어하는 기술이 아닌 팀원을 보여 주면 예산을 낭비하는 팀을 보여 드리겠습니다. 또한, 나는 시간 읽기 시험을 낭비하고 싶어하는 비 기술적 프로젝트의 멤버와 아직 일하고 있지 않습니다. 나도 몰라, 아마 운이 좋은 ...
Graham Ashton

공감. 사용자 용어로 사용자 기능을 설명하는 것은 사용자 가 Cucumber 스토리를 읽었는지 여부에 관계없이 개발자에게 유용합니다. 그렇기 때문에 모든 프로젝트에서 Cucumber를 사용하고 다른 사람들도 이와 같이하도록 권장합니다.
Marnen Laibow-Koser

8

Cucumber 이야기는 개별 코드 비트 (즉, 단위 테스트)가 아니라 애플리케이션이 해결하는 전체 문제에 대한 설명입니다.

Abie가 설명했듯이 거의 응용 프로그램이 충족해야하는 요구 사항의 목록이며 클라이언트와의 통신 및 직접 테스트가 가능합니다.


2
바로 그거죠. 오이는 응용 프로그램의 사용법을 설명합니다. 예를 들어 "여기를 클릭하면이 결과를 얻을 수 있습니다." 사양은 '모델'수준에 있습니다. 마찬가지로, 그런 매개 변수를 사용하여 해당 메소드를 호출하면이 결과를 반환 할 것으로 기대합니다.
Ariejan

6

요즘에는 Capybara 및 Selenium Webdriver와 함께 rspec을 사용할 수 있으며 모든 Cucumber 스토리 파서를 작성 및 유지 관리하지 않아도됩니다. 내가 추천하는 것은 다음과 같습니다.

  1. 당신의 이야기를 쓰십시오
  2. RSpec을 사용하여 다음과 같은 통합 테스트를 작성합니다. spec / integrations / socks_rspec.rb
  3. 그런 다음 새로운 설명을 포함하는 통합 테스트를 작성하고 각 시나리오마다 차단합니다.
  4. 그런 다음 통합 테스트를 얻는 데 필요한 최소한의 기능을 구현하고 컨트롤러 및 모델 등으로 더 깊이 돌아 가면서 컨트롤러 및 모델에서 TDD를 수행합니다.
  5. 다시 통합 테스트를 통과하면 통합 테스트에 단계를 계속 추가 할 수 있습니다
  6. 반복

그러나 컨트롤러와 통합 테스트가 겹치지 않아도 필요하지 않을 수 있으므로 시간을 낭비하지 않도록 최선의 판단을해야합니다.

또한, 일단 그루브를 찾으면 BDD를 사용하여 개발하는 것이 가장 즐겁다는 것을 알게 될 것입니다. 그때까지 완벽하게 생각하지 않고 지나치게 생각하지 않으면 죄책감을 느끼지 않을 때까지. 당신은 잘 할 것입니다!


2

하지만 내 자신의 프로젝트를 수행하면 어떻게됩니까? 대부분의 경우 시스템의 일부가 어떻게 상호 작용하는지 알고 있습니다. 내가해야 할 모든 단위 테스트를 작성하는 것입니다. 오이가 필요할 때 가능한 상황은 무엇입니까?

여전히 오이가 필요합니다. 시스템 작동 방식을 문서화해야하며 변경시 기능이 손상되지 않았는지 확인해야합니다.

다시 말해, 단위 테스트가 필요한 것과 같은 이유로 오이 스토리가 필요합니다. 더 높은 수준의 추상화에서만 작동합니다.


2
Cucumber가 필수적이라고 말하지는 않지만 단위 테스트는 일반적으로 클래스 테스트를 단독으로 사용하기 때문에 일종의 통합 테스트가 필요합니다.
Andy Waite

1
권리. 대부분의 경우 Cucumber는 통합 테스트를 작성하는 가장 좋은 방법입니다.
Marnen Laibow-Koser
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.