BDD-테스트 주도 개발
행동 주도 개발에 대한 참조를 살펴보면 "BDD는 TDD에서 파생됩니다", "BDD 및 TDD"와 같은 구문의 사용을 찾을 수 있습니다. BDD가 어떻게 생겨 났는지, 왜 TDD에서 파생되었다고하는지, BDD와 TDD가 무엇인지 알기 위해서는 TDD에 대해 이해해야합니다.
왜 테스트 하는가?
시작하려면 테스트의 기본 사항을 살펴 보겠습니다. 테스트의 목적은 빌드 된 시스템이 예상대로 작동하는지 확인하는 것입니다. 다음 예를 고려하십시오.
따라서 경험을 통해 결함이 도입되는 즉시 발견하고 즉시 수정하는 것이 비용 효율적이라는 것을 배웠습니다. 따라서 개발 및 테스트의 모든 단계에서 테스트 케이스를 작성해야합니다. 이것은 우리의 전통적인 테스트 관행이 우리에게 가르쳐 준 것이며, 종종 Test-early라고 불립니다.
이 테스트 접근 방식은 테스트가 단계 완료 후 수행되므로 테스트-마지막 접근 방식이라고합니다.
테스트 마지막 접근 방식의 과제
Test-Last 접근 방식은 소프트웨어 개발 프로젝트에서 꽤 오랜 시간 동안 따랐습니다. 그러나 실제로 이러한 접근 방식을 사용하면 테스트가 특정 단계가 완료 될 때까지 기다려야하므로 종종 간과되는 이유는 다음과 같습니다.
무대 완료 지연.
빡빡한 시간표.
테스트를 건너 뛰고 정시에 전달하는 데 집중합니다.
또한 Test-Last 접근 방식에서는 개발자가 수행해야하는 단위 테스트를 건너 뛰는 경우가 많습니다. 발견 된 다양한 이유는 개발자의 사고 방식에 기반합니다.
그들은 개발자이지 테스터가 아닙니다.
테스트는 테스터의 책임입니다.
코딩이 효율적이며 코드에 결함이 없습니다.
결과는-
제공되는 제품의 품질 저하.
테스터에게만 품질에 대한 책임이 있습니다.
결함 수정, 배송 후 비용이 많이 듭니다.
고객 만족도를 얻지 못함은 반복적 인 비즈니스 손실을 의미하므로 신뢰성에 영향을 미칩니다.
이러한 요인은 테스트에 초점을 맞추기 위해 패러다임의 전환을 요구했습니다. 그 결과는 Test-First 접근 방식이었습니다.
테스트 우선 접근 방식
Test-First 접근 방식은 인사이드 아웃 (코드 작성 후 테스트)을 아웃 사이드 인 (테스트 작성 후 코드 작성) 개발 방식으로 대체합니다.
이 접근 방식은 다음과 같은 소프트웨어 개발 방법론에 통합되어 있습니다 (즉, Agile이기도합니다).
이자형X떨다 P로그 래밍 (XP).
T동부 표준시 DRiven D개발 (TDD).
이러한 방법론에서 개발자는 코드 모듈의 한 줄을 작성하기 전에 코드 모듈에 대한 단위 테스트를 설계하고 작성합니다. 그런 다음 개발자는 단위 테스트 통과를 목표로 코드 모듈을 만듭니다. 따라서 이러한 방법론은 단위 테스트를 사용하여 개발을 추진합니다.
목표는 테스트를 기반으로 한 개발이라는 점에 주목해야 할 기본 사항입니다.
빨강-녹색-리팩터링주기
테스트 주도 개발은 단위 테스트에서 안내하는 코드를 개발하는 데 사용됩니다.
Step 1 − 작성 될 코드 모듈을 고려하십시오.
Step 2 − 테스트 작성
Step 3 − 테스트를 실행합니다.
코드가 아직 작성되지 않았기 때문에 테스트가 실패합니다. 따라서 2 단계는 일반적으로 실패 할 테스트 작성이라고합니다.
Step 4 − 테스트를 통과 할 수있는 최소한의 코드를 작성하십시오.
Step 5− 모든 테스트를 실행하여 모두 통과하는지 확인합니다. 이 단계를 용이하게하기 위해 단위 테스트가 자동화됩니다.
Step 6 − 리팩터링.
Step 7 − 다음 코드 모듈에 대해 단계 1 ~ 단계 6을 반복합니다.
각주기는 매우 짧아야하며 일반적인 시간에는 많은주기가 포함되어야합니다.
이것은 또한 널리 알려진 Red-Green-Refactor 사이클, 여기서-
Red − 실패한 테스트 작성.
Green − 테스트를 통과하기위한 코드 작성.
Refactor − 중복을 제거하고 코드를 허용 가능한 표준으로 개선합니다.
TDD 프로세스 단계
TDD 프로세스의 단계는 다음과 같습니다.
TDD의 장점
테스트 주도 개발의 이점 또는 장점은 다음과 같습니다.
개발자는 먼저 코드를 작성하기 전에 원하는 결과가 무엇인지, 테스트 방법을 이해해야합니다.
구성 요소에 대한 코드는 테스트를 통과하고 코드가 리팩토링 될 때만 완료됩니다. 이렇게하면 개발자가 다음 테스트로 이동하기 전에 테스트 및 리팩토링이 보장됩니다.
각 리팩토링 후에 단위 테스트 모음이 실행되므로 각 구성 요소가 여전히 작동하고 있다는 피드백은 일정합니다.
단위 테스트는 항상 데이터에 달려있는 살아있는 문서 역할을합니다.
결함이 발견되면 개발자는 해당 결함을 표시하는 테스트를 만든 다음 테스트를 통과하고 결함이 수정되도록 코드를 수정합니다. 이것은 디버깅 시간을 줄여줍니다. 다른 모든 테스트도 실행되며 통과시 기존 기능이 손상되지 않도록합니다.
개발자는 언제든지 설계 결정을 내리고 리팩토링 할 수 있으며 테스트를 실행하면 시스템이 계속 작동하는지 확인할 수 있습니다. 이것은 소프트웨어를 유지 관리 할 수있게합니다.
개발자는 변경 사항이 기존 기능에 영향을 미치는 경우 테스트를 실행하여 동일한 내용이 드러나고 결함을 즉시 수정할 수 있으므로 변경할 수 있다는 확신이 있습니다.
각각의 연속적인 테스트 실행에서 이전의 모든 결함 수정 사항도 확인되고 동일한 결함의 반복이 감소합니다.
대부분의 테스트는 개발 자체에서 이루어지기 때문에 배송 전 테스트가 단축됩니다.
TDD의 단점
시작점은 시스템의 동작을 설명하는 사용자 스토리입니다. 따라서 개발자는 종종 다음과 같은 질문에 직면합니다.
언제 테스트할까요?
무엇을 테스트할까요?
사양이 충족되는지 어떻게 알 수 있습니까?
코드가 비즈니스 가치를 제공합니까?
TDD에 대한 오해
다음과 같은 오해가 업계에 존재하며 설명이 필요합니다.
| 오인 | 설명 |
|---|---|
| TDD는 테스트 및 테스트 자동화에 관한 것입니다. | TDD는 Test-First 접근 방식을 사용하는 개발 방법론입니다. |
| TDD는 어떤 디자인도 포함하지 않습니다. | TDD에는 요구 사항에 따른 중요한 분석 및 설계가 포함됩니다. 디자인은 개발 중에 나타납니다. |
| TDD는 단위 수준에만 있습니다. | TDD는 통합 및 시스템 수준에서 사용할 수 있습니다. |
| TDD는 기존 테스트 프로젝트에서 사용할 수 없습니다. | TDD는 Extreme Programming에서 인기를 얻었으며 다른 Agile 방법론에서도 사용되고 있습니다. 그러나 기존 테스트 프로젝트에서도 사용할 수 있습니다. |
| TDD는 도구입니다. | TDD는 개발 방법론이며, 새로운 단위 테스트가 통과 할 때마다 새로운 코드가 추가되거나 기존 코드가 수정 될 때마다 그리고 모든 리팩토링 후에 모든 테스트를 실행해야하므로 자동화 테스트 스위트에 추가됩니다. 따라서 TDD를 지원하는 테스트 자동화 도구는이 프로세스를 용이하게합니다. |
| TDD는 개발자에게 수락 테스트를 전달하는 것을 의미합니다. | TDD는 개발자에게 수락 테스트를 전달하는 것을 의미하지 않습니다. |
수락 TDD
ATDD (Acceptance Test Driven Development)는 개발 초기에 사용자 스토리를 생성하는 동안 수락 기준 및 수락 테스트를 정의합니다. ATDD는 고객, 개발자 및 테스터 간의 의사 소통 및 공통 이해에 중점을 둡니다.
ATDD의 주요 사례는 다음과 같습니다.
실제 시나리오에 대해 토론하여 도메인에 대한 공통된 이해를 구축하십시오.
이러한 시나리오를 사용하여 허용 기준에 도달하십시오.
수락 테스트를 자동화합니다.
이러한 테스트에 개발에 집중하십시오.
테스트를 라이브 사양으로 사용하여 변경을 용이하게합니다.
ATDD 사용의 이점은 다음과 같습니다.
요구 사항은 명확하고 기능적 차이가 없습니다.
다른 사람들은 개발자가 예상하는 특별한 경우를 이해합니다.
수락 테스트는 개발을 안내합니다.
TDD 대 BDD
Dan North에 따르면 프로그래머는 일반적으로 Test Driven Development를 수행하는 동안 다음과 같은 문제에 직면합니다.
어디서 시작하나요
테스트 할 항목과 테스트하지 않을 항목
한 번에 테스트 할 양
그들의 테스트를 부르는 것
테스트가 실패한 이유를 이해하는 방법
이러한 모든 문제에 대한 해결책은 행동 기반 개발입니다. 기존의 애자일 관행에서 발전했으며 애자일 소프트웨어 제공을 처음 접하는 팀이 더 쉽게 접근하고 효과적으로 사용할 수 있도록 설계되었습니다. 시간이 지남에 따라 BDD는 애자일 분석 및 자동화 된 승인 테스트의 광범위한 그림을 포함하도록 성장했습니다.
메인 difference between TDD and BDD -
TDD는 소프트웨어 작동 방식을 설명합니다.
반면에 BDD-
최종 사용자가 소프트웨어를 사용하는 방법을 설명합니다.
협업 및 커뮤니케이션을 촉진합니다.
시스템 동작의 예를 강조합니다.
예제에서 파생 된 실행 가능한 사양을 목표로합니다.