테스트 주도 개발은 지난 몇 년 동안 .NET 커뮤니티에서 가장 큰 인기를 끌었습니다. 최근에 ALT.NET 커뮤니티에서 BDD에 대한 불평을 들었습니다. 무엇입니까? TDD와 다른 점은 무엇입니까?
답변
BDD 는 테스트 보다 사양 에 관한 것임을 이해합니다 합니다. 그것은 도메인 주도 디자인에 연결되어 있습니다 (이 * DD 약어를 좋아하지 않습니까?).
높은 수준의 테스트를 포함하여 사용자 스토리를 작성하는 특정 방법과 연결됩니다. Tom ten Thij 의 예 :
Story: User logging in
As a user
I want to login with my details
So that I can get access to the site
Scenario: User uses wrong password
Given a username 'jdoe'
And a password 'letmein'
When the user logs in with username and password
Then the login form should be shown again
(Tom의 기사에서 Tom은이 테스트 사양을 Ruby로 직접 실행합니다.)
BDD의 교황은 Dan North 입니다. BDD 소개 기사 에서 훌륭한 소개를 찾을 수 있습니다.
이 비디오 에서 BDD와 TDD의 비교를 찾을 수 있습니다. 또한 Jeremy D. Miller의 “TDD done right”라는 BDD에 대한 의견
2013 년 3 월 25 일 업데이트
위의 동영상이 잠시 동안 누락되었습니다. 다음은 Llewellyn Falco의 최근 BDD vs TDD (설명) 입니다. 나는 그의 설명이 명확하고 요점을 발견했다.
답변
나에게 BDD와 TDD의 주요 차이점은 초점과 표현입니다. 그리고 말은 당신의 의도를 알리는 데 중요합니다.
TDD는 테스트에 중점을 둡니다. “오래된 폭포 세계”에서 테스트가 구현 된 이후에이 사고 방식은 잘못된 이해와 행동으로 이어집니다.
BDD는 행동과 사양에 중점을 두므로 폭포 정신이 산만 해집니다. 따라서 BDD는 테스트 방식이 아니라 설계 방식으로보다 쉽게 이해됩니다.
답변
BDD에는 두 가지 유형이 있습니다.
첫 번째는 Dan North가 논의한 원래 스타일이며 xBehave 스타일 프레임 워크를 생성했습니다. 나에게이 스타일은 주로 도메인 개체에 대한 승인 테스트 또는 사양에 적용 할 수 있습니다.
두 번째 스타일은 Dave Astels가 대중화 한 스타일이며, 나에게는 새로운 이점 인 TDD의 새로운 형식입니다. 테스트보다는 행동과 소규모 테스트 클래스에 중점을 두어 기본적으로 스펙 (테스트) 방법 당 한 줄을 갖도록 노력합니다. 이 스타일은 모든 수준의 테스트에 적합하며 기존 단위 테스트 프레임 워크를 사용하여 수행 할 수 있지만 최신 프레임 워크 (xSpec 스타일)는 테스트가 아닌 동작에 중점을 둡니다.
유용한 BDD 그룹도 있습니다.
답변
테스트 주도 개발 은 테스트 우선 소프트웨어 개발 방법론으로, 테스트 할 실제 코드를 작성하기 전에 테스트 코드를 작성해야합니다. 켄트 벡의 말에서 :
여기서 스타일은 몇 줄의 코드를 작성한 다음 실행하지 않을 테스트를 작성하는 테스트 또는 실행하는 테스트를 작성하고 실행되는 코드를 작성하는 것입니다.
하나의 작은 코드 조각을 작성하는 방법을 알아 낸 후, 이제는 그냥 코딩하는 대신 즉각적인 피드백을 받고 “약간 코딩하고, 약간 테스트하고, 약간 코드를 작성하고, 조금 테스트하십시오.” 그래서 우리는 즉시 테스트를 작성합니다.
따라서 TDD는 프로그래머가 작동하는 깨끗한 코드를 생성하는 데 사용하는 저수준의 기술 방법론입니다.
행동 주도 개발 은 TDD를 기반으로 만들어졌지만 프로그래머와 테스터에게만 해당되는 것이 아니라 전체 팀과 모든 중요 이해 관계자 (기술적 및 비 기술적)를 다루는 프로세스로 발전한 방법론입니다. BDD는 TDD가 잘 대답하지 못하는 몇 가지 간단한 질문으로 시작했습니다. 얼마나 많은 테스트를 작성해야합니까? 실제로 무엇을 테스트해야합니까? 내가 작성하는 테스트 중 어느 것이 비즈니스 나 제품의 전반적인 품질에 실제로 중요할까요?
보시다시피 이러한 질문에는 기술과 비즈니스 간의 협력이 필요합니다. 비즈니스 이해 관계자와 도메인 전문가는 종종 엔지니어에게 유용한 테스트가 어떤 종류인지 테스트 할 수 있지만 테스트가 중요한 비즈니스 측면을 다루는 고급 테스트 인 경우에만 가능합니다. BDD는“이 기능이 올바르게 작동하는 방법에 대한 예를 알려주십시오”와 같이 비즈니스와 유사한 테스트를“예”라고하며 데이터 유효성 검사 또는 API 통합 테스트와 같은 저수준 기술 검사를 위해“test”라는 단어를 예약합니다. 중요한 부분은 테스트 는 프로그래머와 테스터 만 만들 수 있지만 디자이너, 분석가 등 전체 배달 팀이 예제 를 수집하고 분석 할 수 있다는 것입니다.
한 문장에서, 지금까지 내가 찾은 BDD의 가장 좋은 정의 중 하나는 BDD가“도메인 전문가와 대화하고 원하는 행동을 이해하고 미지의 것을 발견하기 위해 예를 사용하는 것”에 관한 것입니다. 발견 부분은 매우 중요합니다. 배달 팀이 더 많은 예제를 수집할수록 비즈니스 영역을 점점 더 이해하기 시작하므로 처리해야하는 제품의 일부 측면에 대한 불확실성이 줄어 듭니다. 불확실성이 감소함에 따라 전달 팀의 창의성과 자율성이 증가합니다. 예를 들어, 이제 기술 전문 지식이 부족하여 비즈니스 사용자가 불가능하다고 생각한 사례를 제안 할 수 있습니다.
이제 비즈니스 및 도메인 전문가와 대화하는 것이 좋지만 실제로는 그 결과가 얼마나 자주 발생하는지 알고 있습니다. 나는 프로그래머로서 기술로 여행을 시작했다. 프로그래머로서 우리는 알고리즘, 디자인 패턴, 추상화와 같은 코드 를 작성 하도록 배웁니다 . 또는 디자이너 인 경우 디자인— 정보를 구성하고 아름다운 인터페이스를 만듭니다. 그러나 우리가 엔트리 레벨의 일자리를 얻었을 때 고용주는 “고객에게 가치를 제공 할 것”을 기대합니다. 그리고 그 고객들 중에는 은행이 될 수 있습니다. 그러나 계좌 잔고를 효율적으로 줄이는 방법을 제외하고는 은행에 대해 아무것도 알 수 없었습니다. 그래서 나는 어떻게 든 내 코드를 어떻게 든 변환해야 할 것입니다 … 나는 가치를 제공하려면 은행과 기술 전문 지식 사이의 다리를 만들어야합니다. BDD는 배달 팀과 도메인 전문가 간의 안정적인 의사 소통 기반을 기반으로 그러한 다리를 구축하는 데 도움이됩니다.
더 알아보기
BDD에 대해 더 자세히 알고 싶다면 주제에 관한 책을 썼습니다. “훌륭한 사양 작성” 에서는 요구 사항 분석 기술을 살펴보고 훌륭한 BDD 프로세스를 구축하는 방법을 배우고 해당 프로세스의 핵심 부분으로 예제를 사용하는 데 도움을줍니다. 이 책은 유비쿼터스 언어, 예제 수집 및 BDD 팀이 시간과 예산에 따라 훌륭한 소프트웨어를 제공하는 데 도움이되는 기술을 통해 실행 가능한 사양 (자동 테스트)을 생성하는 것에 대해 설명합니다.
“Writing Great Specification”을 구매 하고 싶다면 프로모션 코드 39nicieja2로 39 % 를 절약 할 수 있습니다. 🙂
답변
BDD 접근 방식에 대해 약간 실험했으며 BDD가 사례 구현에 적합하지만 기본 세부 사항에는 적합하지 않다는 결론을 내 렸습니다. TDD는 여전히 그 수준에서 흔들리고 있습니다.
BDD는 통신 도구로도 사용됩니다. 목표는 도메인 전문가가 이해할 수있는 실행 가능한 사양을 작성하는 것입니다.
답변
BDD가 더 넓은 범위 인 것 같습니다. 그것은 TDD가 사용되었음을 암시하며, BDD는 빠른 피드백을 보장하기 위해 TDD 사례를 사용하기위한 정보와 요구 사항을 수집하는 포괄적 인 방법론이라는 것을 의미합니다.
답변
TDD와 비교할 때 BDD에 대한 최신 지식을 바탕으로 BDD는 다음에 일어날 일을 지정하는 데 중점을 두는 반면, TDD는 조건 세트를 설정하고 출력을 보는 데 중점을 둡니다.
