레일즈에 관심이 많기 때문에 우연히 루비 인사이드의 가입자가되었습니다. 어제, Rails의 제작자 인 David Heinemeier Hansson은 테스트/유닛을 사용하고 있다고 거의 말했다. 내부의 레일이기 때문에 나는 이해할 것이다. 그러나 그는 강한 견해를 가진 것으로 보인다. 그는 RSpec과 오이가 불필요하게 복잡하다고 믿습니다.DHH 단위 테스트 : RSpec은 실제로 불필요하게 복잡합니까?
나는 보통 많은 관심을 기울이지 않지만, 누가 무엇을 말하고 있는지에 달려있다. 나는 Hansson을 많이 존경하고 그의 생각은 나를 생각하게했다. Rails를 시작했을 때 나는 테스트/유닛을 직접 들여다 보지 못했습니다. 그냥 RSpec과 오이.
그래서 나는 당신의 통찰력을 원합니다. 당신은 RSpec이 참으로 부가 가치가 없으면 복잡하다고 생각합니까? 필기 시험/단원은 시간과 노력이 적습니까?
필자는 Shoulda (extends Test :: Unit) 또는 RSpec을 Capybara와 -no- Cucumber와 함께 사용하는 것이 좋습니다.
중첩 된 컨텍스트에 대한 RSpec 또는 Shoulda의 사용은 확실히 가치가 있다고 생각합니다. RSpec은 확실히 무거운 무게 (아마도 과체중)이지만, 나는 그 이유로 울타리에있다.
오이, 마침내 알게되었습니다. 보통 가치가있는 것보다 더 귀찮습니다. 평범한 통합 테스트와 카피 바라 (Capybara)를 사용하여보다 간단하고 확실하게 필요한 것을 성취 할 수 있습니다. 기억해라 - Capybara! = 오이. 그리고 Capybara는 그 자체로 아주 유능하다.
표준 Test :: Unit 프레임 워크에 편의를 추가하기 때문에 RSpec보다 훨씬 가볍습니다 (기술적으로 각각 다른 세트의 문제를 해결하지만 둘 다 중첩 된 컨텍스트 기능을 제공합니다).). RSpec은 어서션을 자연스럽게 읽는 장점이 있으며 어설 션에 메시지 인수를 쓰지 않아도 많은 경우에 도움이되는 실패 메시지를 생성합니다.
또한 Cucumber는 실제로 RSpec이 필요하지 않으므로 Cucumber를 계속 사용하려면 Test :: Unit 만 사용하면됩니다. 선택의 폭이 넓습니다.
실제로 rpsec에서 무료로 제공되는 automagic 실패 메시지는 큰 매력입니다. –
오! ;) –
나는 그 글을 썼기 때문에 나는 오이가 그렇게 성가신 일이 필요 없다는 것을 배웠다. 모든 프로젝트에 적합하지는 않지만 사양을 체계화하는 데 매우 가치있는 방법 일 수 있습니다. 좋은 오이 테스트를 작성하는 열쇠는 비즈니스 가치 측면에서이를 작성하고 특정 구현에 경의를 표하는 것입니다. Gherkin에 '페이지'또는 '클릭'과 같은 단어가 포함 된 경우 그다지 좋지 않습니다. 또한, 오이 검사는 꼭 가득 차있을 필요는 없습니다. 오이 테스트는 전체 스택 검증을 위해 Capybara를 통해 작동하는 몇 가지 통합 테스트로 낮은 수준에서 실행될 수 있습니다. –
모두 의미론입니다. RSpec과 Test :: Unit은 기능적으로 유사합니다. 개인적으로 항상 RSpec을 선호했습니다. 왜냐하면 RSpec을 사용하여 테스트를 작성하는 것이 자연 스럽다는 것을 알았 기 때문입니다. 나는 또한 custom matchers을 쓰는 단순함을 좋아하며 제공된 기본 matcher가 유용하다.
오이는 완전히 다른 짐승입니다. 그렇습니다. 단계 정의를 올바르게 구성하지 않으면 매우 성가 시며 유지 보수가 어려워집니다. 그러나 매우 강력한 유스 케이스가 있으며 클라이언트가 스펙을 작성하고있는 경우입니다.
저는 고객이 QA 팀과 함께 오이 시나리오를 작성한 프로젝트를 진행했습니다. 비 기술적 인 사람으로서 코드에서 사용자 스토리를 지정하는 것은 매우 친숙하고 자연스러운 방법입니다. 오이는 우리의 민첩한 행동을 따를 때 걷는 데 정말로 도움이되었습니다. 최종 제품의 품질은 그로부터 이익을 얻었지만 전혀 그렇지 않습니다. 은과 같습니다.
개인적인 취향입니다.
나는 세부 사항에 대해 걱정하지 않고 쉬운 오이 테스트를 작성하는 것을 좋아합니다. 그냥 내 애플의 "행복"경로를 테스트. (휴대용, 이해할 수있는, 천천히)
나는 시험/단위에게 세부 사항을 맡긴다.(쉽게, 빨리가)
그것은 이해하는 데 시간이 더 소요 : 테스트가 동일하지
get :products, :session => @session_id_for_product_banana
assert_select "table" do
assert_select "td#name", "Banana"
end
대신
When I go to the banana page
Then I should see "Banana"
물론
의하지만 누가 "바나나"사업부에 있는지 관심이나 테이블 또는 올바른 html-id가 없습니다.리팩토링 후 ID가 없어 질 수 있기 때문에 기능 테스트가 마음에 들지 않아 세션 기대치가 변경 될 수 있습니다. 그렇다면 코드 및 테스트를 리팩토링해야합니다. 오이를 사용한다면 시나리오를 바꿀 필요가 없습니다.
"바나나"가 "바나나": 문자열 "에 대해"정의되지 않은 메서드 '찾기'라는 오류 메시지의 일부가 아닌 테이블에있는 "바나나"에 관심이 있다면 어떨까요? – Arsen7
그럴 수도 있지만 가능성은 없습니다. ID가 변경되거나 div를 사용하기로 결정했을 가능성이 훨씬 큽니다. 뷰에 로직이 포함되어 있지 않으면 일반적으로 유닛 테스트에서 이러한 유형의 오류가 발생합니다. 또한 Cucumber는 런타임 오류시 스택 추적으로 너무 날아 가기 쉽습니다. –
레일 테스트/유닛이 좋기 때문에 DHH에 동의합니다. 나는 프레임 워크, rspec, 셀레늄 등을 테스트하는 레일을 사용했고, DHH – Ashish
과 같은 느낌이 들었다. 상대적으로 동결 된 요구 사항은 말할 필요도없이 BDD/TDD는 DHH가 말한 것에 충실합니다. 그는이 블로그 게시물을 작성해 주셔서 감사합니다. – Abs