BDD는 중대형 프로젝트에 확장 가능합니까?

BDD (Behaviour Driven Development)에 대한 모든 웹 사이트에서 요구 사항을 정의하는 것이 얼마나 명백하고 쉬운지를 보여주는 매우 간단한 좋은 예를 찾을 수 있습니다. 그러나이 예제를 큰 제품 (계산기 예제가 아닌)으로 구현하려고하면 상황이 꽤 복잡하고 읽을 수 없다는 것을 알 수있었습니다. 특히 나중에 요청을 변경하면 통합 테스트를 수정하기위한 많은 작업이 필요합니다.

BDD가 정말로 가치가 있습니까? 다른 기술로는 해결되지 않는 문제를 해결합니까?

나는에서 최고의 자원 중 하나라고 생각 BDD는 이다 예에 의한 사양 책. BDD 테스트를 구성하는 방법과 요구 사항이 변경 될 때 재 작업을 유발하지 않도록 작성해야하는 방법에 대해 설명합니다.

테스트에서 문제가 복잡하거나 복잡해지면 뭔가 잘못한 것일 수 있습니다. BDD 및 TDD와 동일합니다. 좋은 시험을 작성하는 것은 어렵고 그것을 배우는 데 몇 달이 걸립니다.

BDD의 초점이 대화 라는 것을 깨닫는 것이 도움이 될 수 있습니다 . BDD는 실제로 훌륭한 부산물로서 약간의 회귀 테스트를 제공하는 분석 도구입니다.

대화의 모든 수준에서 시나리오를 사용했습니다. 다른 이해 관계자 식별 에서 릴리스가 잘 수신 될 수 있는지 확인하고 모듈 또는 클래스의 작동 방식을 연구합니다 .

이것을 쉽게하기 위해 제안 할 수있는 몇 가지 힌트와 팁이 있습니다.

이전에 해본 적이 없다면 변경 될 것입니다.

도메인이나 비즈니스에 새로운 것은 바뀔 수 있습니다. 시나리오를 통해 이야기하고 질문하고 비즈니스가 "오, 잘 모르겠습니다"라고 말하면 이 공간에 있다는 것을 알게 될 것 입니다. 이는 BDD를 중단하고 더 빠른 피드백을 얻기 위해 무언가를 스파이 킹하여 비즈니스가 원하는 것을 해결하도록 돕는 좋은 신호입니다. 일단 아이디어가 안정되면 시나리오를 소급하여 작성할 수 있습니다.

모든 프로젝트에는 새로운 측면이 있거나 그렇지 않을 것입니다.

이전에 해본 적이 있다면 지루합니다.

새롭고 차별화 된 측면 뿐만 아니라 , 프로젝트는 일반적으로 이미 수행 된 것과 유사한 일부 범용 측면을 가지고 있습니다. 예를 들어, 새 휴대 전화를 생산하는 경우에도 전화를 걸어야합니다. "전화 걸기"는 잘 알려진 시나리오로서이를 통해 대화 할 필요는 없습니다. 마찬가지로 "로그인"또는 "사용자 등록"과 같은 것은 지루합니다.

가능하면 라이브러리를 사용하면 시나리오를 작성할 필요가 없습니다. 또한 다른 비트를 먼저 수행하십시오. 이미 로그인 한 사용자가 있고 자신이 로그인 한 내용 을 해결하십시오 . 이러한 영역은 변경되지 않으므로 수동 테스트를 수행하지 않아도됩니다.

누군가 전에 해본 적이 있다면 시나리오를 통해 이야기하는 것이 도움이 될 수 있습니다.

우리는 도메인 특정 요구 사항이 있는 곳, 누군가 가 상대적으로 잘 이해 하고있는 부분과 실제 불확실성이 시스템의 실제 행동이 아닌 범위를 중심으로하는 부분 사이에 약간의 차이가 있습니다.

시나리오를 통해 이야기하면 개발자 팀이 행동을 발견하고 전문가의 지식을 활용하며 알려진 귀중한 행동을 포착 할 수 있습니다.

이것이 BDD가 가장 잘 작동하는 부분입니다. 내 팁은 기능 파일의 맨 위에 가장 흥미로운 시나리오 (또는 자동화하지 않은 경우 Wiki)를 작성하고 결과적으로 복제되거나 추론하기 쉬운 시나리오를 삭제하는 것입니다.

가능하면 시나리오를 응용 프로그램 작동 방식의 예로 사용하십시오 . 예를 들어, 유효성 검사 작동 방식을 보여 주려면 응용 프로그램이 사용자가 양식을 작성하는 데 어떻게 도움이되는지 몇 가지 예를 보여줍니다. 유지 보수가 훨씬 쉽고 실행이 더 빠른 단위 테스트를 통해 유효성 검사가 엄격한 지 확인하십시오.

추가 자료

이것에 관심이 있다면, 내가 쓸 수있는 것들이 있습니다.

큰 BDD

개발자를위한 Cynefin. 이 세 영역에 대해 자세히 설명합니다.

내 튜토리얼 슬라이드 는 모두 훌륭하고 주석이 달려 있으며 전체 스택도 포함합니다.

지난 가을에 상당히 복잡한 ( 도메인 복잡성 ) 프로젝트를 구축했으며 BDD에 선행 작업을하면 프로젝트가 저장되었다고 솔직하게 말할 수 있습니다. 도메인 복잡성과 BDD의 이점 사이에는 강한 상관 관계가 있습니다.

복잡한 비즈니스 규칙을 테스트하는 것은 어렵습니다. 문제는 변경을 할 때마다 모든 미친 시나리오를 시도하고 기억하고 싶거나 안전망이 스펙을 어겼을 때 알려주기를 원한다는 것입니다. 선행 시간을 보내고 모든 시나리오를 해결하고 기록한 다음 결국 모든 테스트를 작성하십시오.

나중에 다시 이해하려고 시도 할 때 테스트 가능한 사양을 갖추면 생명을 구할 수 있습니다.

BDD는 TDD (Test Driven Development)를 기반으로 한 개발 프로세스입니다. 개인적인 경험에서 얻은 TDD의 장단점은 다음과 같습니다.

• TDD, 범위가 잘 정의되어 있는지 확인하십시오. 이런 식으로 테스트 케이스를 먼저 디자인합니다. 따라서 작성해야 할 코드 조각에 대한 기대치를 설정합니다.
• TDD는 코드를 보호하는 방법입니다. 간단한 함수를 작성하고 나중에이 동일한 함수에 복잡한 전환 조건을 추가한다고 가정하십시오. 내일 누군가 다른 사람이이 기능을 수정하려면 테스트 사례를 참조하십시오. 사용자가 기능을 변경하려면 테스트 케이스도 변경해야합니다 (대부분의 경우). 이것은 당신이 쓴 것에 대한 추론이 있음을 이해할 수있게합니다.
• TDD는 더 빠른 소프트웨어 개발을 가능하게합니다. 우리 각자는 코딩하는 동안이 문제에 직면했을 것입니다. 우리는 아이디어부터 시작합니다. 그리고 천천히 추적하십시오. 우리는 일부 시나리오를 처리하기 위해 원치 않는 코드 조각을 넣습니다. TDD에서는 사전에 기대치를 설정합니다. 따라서 목표에서 너무 멀리 벗어나는 것을 제한합니다.
• TDD를 사용하면 프로젝트가 온라인 상태가되기 전에 가능한 버그를 잡을 수 있습니다. 이것은 주로 작성된 테스트 케이스의 품질과 관련이 있습니다.

단점 :

• 처음에는 TDD가 약간 까다로울 수 있습니다. 많은 사람들이 개발을 주도하는 테스트 케이스의 개념을 이해하지 못합니다.
• TDD는 때때로 유지 관리에 많은 노력을 기울일 수 있습니다. 이는 원치 않거나 의미없는 테스트 사례와 관련이 있습니다.
• TDD는 소금을 꼬집어 야합니다. 다른 사람이 작성한 테스트 사례에 시간을 보내는 것을 좋아하는 개발자는 없습니다. 테스트 케이스의 의미를 해독하면 때로는 심각한 두통이 발생할 수 있습니다.

900,000 줄 이상의 코드로 프로젝트를 진행하고 있습니다. 그리고 나는 여전히 BDD를 따릅니다. 고려해야 할 한 가지 중요한 것은 테스트 사례로 인해 순전히 포착 할 수있는 가능한 오류의 수입니다. 몇 년이 지나면 BDD가 맹세합니다!