BDD vs TDD vs ATDD : 주요 차이점
이 가이드 포스트는 행동 주도 개발 (BDD), 테스트 주도 개발 (TDD)과 같은 다양한 테스트 방법 또는 관행을 설명하는 것을 목표로합니다. ), 수락 테스트 주도 개발 (TDD). 또한 이러한 기술 간의 주요 차이점을 명확히하는 데 도움이됩니다. 이 기사를 마치면 각 방법의 작동 방식, 주요 차이점 및 개발 프로세스에서의 특정 역할을 이해하게 될 것입니다.
먼저 테스트 주도 개발부터 시작하겠습니다.
TDD (Test-Driven Development) 란 무엇입니까?
Test-Driven Development는 개발자의 관점에서 구현 된 테스트 방법 또는 프로그래밍 관행입니다. 이 기술에서 QA 엔지니어는 애플리케이션의 모든 작은 기능에 대한 테스트 케이스를 설계하고 작성하기 시작합니다. 이 기술은 간단한 질문에 답하려고합니다. 코드가 유효합니까? 이 기술의 주요 목적은 테스트가 실패 할 때만 새로운 코드를 수정하거나 작성하는 것입니다. 따라서 테스트 스크립트의 중복이 줄어 듭니다. 이 기술은 애자일 개발 생태계에서 널리 사용됩니다. TDD 접근 방식에서 자동화 된 테스트 스크립트는 기능적인 코드 조각보다 먼저 작성됩니다. TDD 방법론에는 다음 단계가 포함됩니다.
- 문서에 지정된 요구 사항에 따라 개발자가 자동화 된 테스트 사례를 작성합니다.
- 이러한 테스트가 실행되고 일부 경우 , 실제 기능을 개발하기 전에 개발 되었기 때문에 실패합니다.
- 그런 다음 개발 팀은 테스트가 성공적으로 통과 할 수 있도록 코드를 리팩터링합니다.
리팩토링 주요 기능이나 동작을 변경하지 않고 코드를 수정하는 프로세스를 나타냅니다. 
테스트 주도 개발의 이점 :
- 재 작업에 필요한 시간 단축
- 버그 나 오류를 매우 빠르게 탐색 할 수 있습니다.
- 더 빠른 피드백을 얻을 수 있습니다.
- 더 깔끔하고 더 나은 디자인을 개발하도록 장려합니다.
- 프로그래머의 생산성을 향상시킵니다.
- 특정 팀원이없는 경우 모든 팀원이 코드 작업을 시작할 수 있습니다. 이를 통해 지식 공유 및 협업이 촉진됩니다.
- 프로그래머가 애플리케이션의 대규모 아키텍처를 쉽게 변경할 수 있다는 확신을줍니다.
- 유연하고 유지 관리가 쉬운 광범위한 코드를 생성합니다.
li>
이제 행동 중심 개발에 대한 모든 것을 이해하겠습니다.
행동 중심 개발 (BDD)이란 무엇입니까?
비즈니스 중심 개발 (BDD) TDD (Test-Driven Development) 방법론에서 파생 된 테스트 접근 방식입니다. BDD에서 테스트는 주로 시스템 동작을 기반으로합니다. 이 접근 방식은 동작을 기반으로 기능을 개발하는 다양한 방법을 정의합니다. 대부분의 경우 Given-When-Then 접근 방식이 테스트 케이스 작성에 사용됩니다. 이해를 돕기 위해 예를 들어 보겠습니다.
- 사용자가 유효한 로그인 자격 증명을 입력 한 경우
- 사용자가 로그인 버튼을 클릭 할 때
- 그런 다음 표시 성공적인 유효성 검사 메시지
위에 표시된 것처럼 동작은 공유 언어라고도하는 매우 간단한 영어로 설명됩니다. 이렇게하면 개발을 담당하는 팀의 모든 구성원이 기능 동작을 이해하는 데 도움이됩니다.
예를 들어 다음과 같이 여러 기기에서 테스트하기위한 일련의 지침을 기반으로 쉬운 크로스 브라우저 테스트를 실행할 수 있습니다. 동영상.
무료로 Real Device Cloud에서 브라우저 테스트 사용해보기
행동 중심의 주요 이점 개발 접근 방식 :
- 비 기술적 언어를 사용하여 더 많은 잠재 고객에게 다가 갈 수 있도록 지원
- 시스템이 고객 및 개발자의 관점에서 어떻게 작동해야하는지에 중점을 둡니다.
- BDD는 비용 효율적인 기술입니다.
- 배포 후 결함을 확인하는 데 필요한 노력을 줄여줍니다.
아래 이미지는 일반적인 BDD 작업을 보여줍니다.
이미지 출처 : Tutorialspoint
SDLC에서 BDD가 어떻게 도움이 되나요?
개발 라이프 사이클의 후반 단계에서 오류를 디버깅하는 것은 종종 비용이 많이 듭니다. ive. 대부분의 경우 요구 사항을 이해하는 데있어 모호함이이 문제의 근본 원인입니다. 모든 개발 노력이 미리 결정된 요구 사항을 충족하도록 유지되도록해야합니다. BDD를 통해 개발자는 다음과 같은 방법으로 위의 작업을 수행 할 수 있습니다.
- 간단한 영어를 사용하여 표준 접근 방식으로 요구 사항을 정의 할 수 있도록 허용
- 이해를위한 실제 시나리오를 설명하는 여러 방법 제공 요구 사항
- 기술 팀과 비 기술 팀이 협력하고 요구 사항을 이해할 수있는 플랫폼 제공
수락 테스트 주도 개발이란 무엇입니까?
ATDD (Acceptance Test-Driven Development) 기법에서는 사용자의 관점에서 단일 수락 테스트가 작성됩니다.주로 시스템의 기능적 동작을 만족시키는 데 중점을 둡니다. 이 기술은 코드가 예상대로 작동합니까?
이 기술은 공통적 인 초점을두고 개발자, 사용자 및 QA 간의 협업을 향상시킵니다. 허용 기준 정의. 다음은 ATDD의 몇 가지 주요 사례입니다.
- 실제 시나리오 분석 및 논의
- 해당 시나리오에 대한 허용 기준 결정
- 승인 테스트 사례 자동화
- 이러한 요구 사항 사례 개발에 초점
ATDD의 이점
- 요구 사항은 모호함
- 팀 간 협력을 장려
- 승인 테스트는 전체 개발 프로세스의 가이드 역할을합니다.
주요 차이점 : TDD vs BDD vs ATDD
| 매개 변수 | TDD | BDD | ATDD |
| 정의 | TDD는 기능 구현에 더 초점을 맞춘 개발 기술입니다 | BDD는 시스템 동작에 초점을 맞춘 개발 기술입니다. | ATDD는 요구 사항을 포착하는 데 더 초점을 맞춘 BDD와 유사한 기술입니다. |
| 참가자 | 개발자 | 개발자, 고객, QA | 개발자, 고객, QA |
| 사용 언어 | 기능 개발에 사용되는 언어와 유사한 언어로 작성되었습니다 (예 : Java, Python 등) | 단순 영어, (Gherkin) | 단순 영어, Gherkin |
| 주요 초점 | 단위 테스트 | 요구 사항 이해 | 승인 테스트 작성 |
| 사용 된 도구 | JDave, Cucumber , JBehave, Spec Flow, BeanSpec, Gherkin Concordian, FitNesse | Gherkin, Dave, Cucumber, JBehave, Spec Flow, BeanSpec, Concordian | TestNG, FitNesse, EasyB, Spectacular, Concordian, Thucydides |
이러한 방법의 작동 방식을 이해하면 소프트웨어에 관련된 개발자 및 기타 개인에게 도움이 될 수 있습니다. 개발 목적에 가장 적합한 전략이 무엇인지 파악합니다. 프로젝트의 종류와 달성하고자하는 결과에 따라 가장 효율적인 방법으로 특정 요구 사항을 충족하는 올바른 방법 (또는 여러 방법의 혼합)을 배포 할 수 있습니다.