Java 용 BDD 프레임 워크의 차이점은 무엇입니까? [닫은]

Java 용 각 BDD ( Behavior Driven Development ) 프레임 워크 의 장단점은 무엇입니까 ?

예를 들어 여기 에서 일부를 찾았습니다 .

이미 모의 라이브러리 (예 : Mockito )를 사용하고 있다면 BDD 프레임 워크를 사용하는 것이 합리적 입니까?

방금 Java 용 BDD 프레임 워크 세 가지 비교를 마쳤습니다. 분명히 내 결과는 사용 기한이 상당히 짧습니다.

콩 코디 언

• 매우 유연함
• 매우 예쁜 보고서 출력
• 멋진 플러그인 프레임 워크
• 제대로 문서화되지 않았습니다. 나는 그것을 알아 내기 위해 소스를 읽어야했다 (다행히도 매우 좋은 품질).
• 고정물은 html과 밀접하게 결합되는 것처럼 보였습니다.

EasyB

• 매우 얕은 학습 곡선 (Groovy가 아닌 개발자도 해당)
• 매우 강력한 DBUnit 통합
• 분명히 매개 변수에 대한 지원이 없습니다 (매우 모호한 이야기 ​​나 텍스트와 코드 사이의 중복으로 이어집니다 (편집 : 실제로는 있지만 문서는 매우 잘 숨겨져 있음).)
• 스토리와 코드는 매우 밀접하게 결합되어 있습니다 (동일한 파일).
• 매우 기본적인 보고서 출력
• IntelliJ 플러그인이 작동하도록 할 수 없습니다.
• 비활성 커뮤니티 (Maven 플러그인이 3 개월 동안 중단 된 것으로 보임-그릴 코드 예제가 많지 않음)

JBehave

• 매우 강력하고 유연함 (예 : 전제 조건으로 스토리 구성을 통한 상용구 감소)
• 광범위한 (조각화 된 경우) 문서 및 예제
• 다양한 프레임 워크 및 환경에 대한 광범위한 (압도적 일 경우) 지원
• 코드에서 스토리 파일의 탁월한 분리
• 꽤 활발한 커뮤니티와 웹에서 더 많은 예제와 토론이있는 것 같습니다.
• 상당히 가파른 학습 곡선 (Concordion / EasyB보다 파악하는 데 3 ~ 4 배 더 오래 걸림)

나는 내가 원했던 것처럼 JDave의 Cuke4Duke를 시험해 볼 기회가 없었지만 아마도 지금은 JBehave를 추진할 것입니다.

"장단점"은 사람마다 다를 수 있습니다. 나는 보통 봐

• 개발 활동 , 예를 들어 새로운 릴리스 일 가능성이 있거나 2 년 된 마지막 릴리스입니다.
• 성숙도 , 예를 들어 얼마나 오래 있었는지, 튜토리얼이 있고 책이있을 수도 있습니다. (저는이 책을 읽지 않고 입양의 신호일뿐입니다.)
• 도구 지원 , 예 : Eclipse 플러그인, Ant 지원 등
• 의존성의 크기 , 나는 그들 자신의 모든 것을 제공하는 프레임 워크를 좋아하지 않는다. 예를 들어 저도 조롱하는 프레임 워크를 직접 선택하고 싶습니다.
• 종류의 라이센스 , 이것은 내가 일하는 회사의 법적 조건 때문에 나에게 중요합니다.
• 관련 도구와의 호환성 , 예를 들어 Gherkin 언어를 사용하는지 여부.

그리고 일부 프레임 워크에서

• 본능 나쁨 : 마지막 활동 2010 년 3 월, 좋음 : ASF 라이선스
• JDave bad : matchers 및 mocks와 함께 제공, good : 마지막 활동 2011 년 1 월, ASF 라이센스
• easyb bad : 2010 년 10 월 마지막 활동, 확실하지 않음 : Groovy를 사용합니다. 이것은 괜찮을지 모르지만 제 경우에는 입양에 문제가 될 것입니다.
• beanspec bad : 2007 년에 단 하나의 버전, 이것은 죽었습니다
• bdoc bad : 2010 년 1 월 마지막 활동, 확실하지 않음 : 코드에서 보고서를 만드는 반대 방향으로 진행되는 것 같습니다.
• spock bad : 약간 극단적 일 수도 있습니다. 이것은 BDD뿐만 아니라 완전한 테스트 프레임 워크입니다. 좋음 : 매우 활동적이고 매우 멋집니다.
• jbehave , Java에서 모든 BDD의 "어머니", 나쁨 : 매우 강력 함 = 복잡하고 호환되지 않는 라이센스 (나에게), 거의 모든 테스트 라이브러리와 함께 제공됨 ,훨씬 더 좋음 : RSpec 기반이므로 호환 가능, Eclipse 플러그인, Maven 통합 , 매우 활동적인 커뮤니티
• ginkgo4j , Java 용 BDD 프레임 워크도 Ruby의 RSpec을 기반으로하지만 Java 람다 (주석 대신)를 사용하여 상황에 맞는 매우 읽기 쉬운 테스트를 만들 수 있습니다. 단순한. 아주 세다. 오픈 소스 Apache 2 라이선스.

모의에 관하여 : 분명히 모의 프레임 워크도 필요합니다. BDD 프레임 워크는 사양 작성에 도움이 될 뿐이지 만 일부 테스트에는 모의 또는 스텁이 필요합니다. 하향식으로 디자인 할 때 (개요에서 세부 사항까지).

Java와 함께 사용하기에 가장 좋은 BDD 프레임 워크는 무엇입니까? 왜? 각 프레임 워크의 장단점은 무엇입니까?

Concordion vs. Cucumber 및 Java 기반 수락 테스트에 대한 흥미로운 링크가 있습니다.

여기에서 몇 개를 찾았지만 어떤 것을 선택해야할지 모르겠습니다.

정말로 위에서 언급 한 것을보세요.

이미 모의 라이브러리 (예 : Mockito)를 사용하고 있다면 BDD 프레임 워크를 사용하는 것이 합리적입니까?

짧은 대답 : 그렇습니다. 실제로 BDD 프레임 워크를 사용하는 수용 테스트와 모의 개체를 사용하는 격리 단위 테스트는 너무 다르기 때문에 실제로 질문을받지 못합니다. 수락 테스트는 블랙 박스 테스트이며, 테스트는 비즈니스 기능이 작동하는지 확인하는 데 사용되며 비즈니스 분석가가 이상적으로 작성합니다. 모의를 사용한 격리 된 단위 테스트는 화이트 박스 테스트이며 테스트는 단위가 작동하고 개발자가 작성했는지 확인하는 데 사용됩니다. 둘 다 유용하지만 완전히 다른 목적을 가지고 있습니다. 즉, Mockito를 사용하는 것은 BDD 프레임 워크를 전혀 대체하지 않으며 그 반대도 사실입니다.

나는 원래 평범한 jUnit 으로 BDD를했지만 최근 에 JDave를 살펴 보았다. jUnit 으로했던 것과 거의 1 : 1이기 때문이다. 또한 jUnit 위에서 실행되므로 이미 Eclipse에서 작동하며 Hudson과 같은 연속 통합 시스템에서 작동하도록 구성하기 쉽습니다. 다른 사람들과 비교할 수는 없지만 JDave에 대한 나의 경험은 지금까지 좋았습니다.

오 그리고 모의를 사용하는 것은 결코 어리석은 생각이 아닙니다! 특히 TDD / BDD에 묶여 있지는 않으며, 일반적인 테스트의 부담을 덜어주는 것이 목적입니다.

와, 주제가 뜨겁고 좋은 답변이 많네요 ...

아이러니를 제외하고, 나는 최근에 BDD를 발견했고 그 개념이 흥미 롭다는 것을 발견했습니다. 이봐, 테스트와 사양을 모두 작성해야합니다! 놀랍게도 후자는 일부 프로젝트에서 누락 될 수 있습니다. 또는 BDD가 도입해야하는 정밀도가 부족할 수도 있습니다.

개발에 힘 입어 행동 기사는 좋은 기사에 대한 개념과 링크를 요약 한 것입니다 (앤드류 글로버가 쓴 것과 같은). 또한이 스레드의 주제에 대해 BDD 프레임 워크의 포괄적 인 목록을 제공합니다. 그 중 상당수는 Java 용입니다.
프레임 워크를 선택하는 문제는 해결되지 않지만 적어도 검색이 쉬워집니다.

BDD는 테스트 코드의 가독성에 크게 의존하기 때문에 선택의 좋은 기준은 빠른 둘러보기 / 튜토리얼을보고 어떤 것이 자신의 스타일에 더 잘 맞는지 확인하는 것입니다. 다른 기준은 프레임 워크가 익숙한 도구 (단위 테스트, 모의), IDE 사용 등을 활용한다는 사실 일 수 있습니다.

나는 시도 오이 - JVM (이전 Cuke4Duke으로 개발을). 일반 텍스트로 저장되는 사양에 Gherkin DSL을 사용합니다.

JUnit 테스트로 실행할 수 있습니다. 따라서 사용을 시작하는 유일한 문제는 비즈니스 사람이나 제품 관리자가 소스에서 .features를 읽고 쓰도록하는 것입니다.

결과

우리 팀은 JBehave를 사용하고 있습니다. 를 사용하고 있습니다. 일반 텍스트 파일을 사용하여 사양을 저장합니다. 그런 다음 모든 단계 (Given, When, Then)는 단계에서 매개 변수를 추출 할 수있는 특정 방법에 의해 실행됩니다. 시나리오는 들여 쓰기 및 형식이 잘 지정 될 수 있으므로 클라이언트가이를 확인하려는 경우 많은 도움이됩니다.

몇 가지 문제도 있습니다. Java 6으로 전환했습니다. 실행 중에 일부 시나리오 단계가 무시되는 경우가 있습니다. 버그가 어디에 있는지 파악하는 데 많은 문제가 발생할 수 있습니다.

우리 팀은 JBehave를 성공적으로 사용했습니다. 우리는 EasyB를 사용한 후에 JBehave로 이동했고 일반 텍스트 시나리오 파일을 다루기가 더 쉽다는 것을 알게되었습니다.