TDD?? BDD??

uglyduck.dev·2020년 9월 27일

agile

개념 모아 🗂

목록 보기

32/40

TDD(Test Driven Development)

정의

테스트 코드를 작성하고 테스트로 검증된 코드를 가지고 실제 코드를 작성하는 애자일의 대표적인 개발 방법론

목적

실패한 단위 테스트가 있는 경우에만 코드 작성
리팩토링 / 제거 중복

개념

개발 전에(새 코드 작성하기 전)에 실패한 테스트를 작성하고 수정하는 것. 테스트를 통과하기 위해 한 번에 적은 양의 코드를 작성하므로 코드 중복을 피할 수 있음. 실제 애플리케이션 개발 전에 자동화된 테스트를 개발하고 실행하는 프로세스이므로 때때로 Test First Development라고도 함

수행 방법

수행 방법
1. 테스트를 추가해라
2. 모든 테스트를 실행하고 새로운 테스트가 실패했는지 확인해라
3. 코드를 작성해라
4. 테스트 및 리팩터 코드를 실행해라
5. 반복

장점

초기 버그 알림
- 개발자는 코드를 테스트하지만 데이터베이스에서는 주로 수동 테스트 또는 일회용 스크립터로 구성됨. TDD를 사용하면 시간이 지남에 따라 본인과 다른 개발자가 자유롭게 재실행 할 수 있는 자동화된 테스트를 구축할 수도 있음
더 빠른 개발자 피드백 루프
- TDD가 없으면 개발자는 각 변경 사항을 수동으로 테스트하여 작동하지 확인해야 함. TDD를 사용하면 단위 테스트 변경 시 자동으로 실행될 수 있으므로 개발 및 디버깅 세션 중에 더 빠른 피드백을 제공
인터페이스 설계 지원
- 개발자는 소프트웨어 구성 요소를 사용하는 개발자 경험에 대해 생각하기 전에 소프트웨어 구현에 대해 생각함. TDD는 이를 뒤집어 개발자가 구현 작업을 하기 전에 API를 설계하도록 함
리팩토링에 대한 자신감
- 최소한의 위험으로 업데이트할 수 있는 버그가 적고 더 빠르고 확장 가능한 코드 생성
개발자에게 이로움
- 테스트 사례를 작성하는 데 더 많은 시간을 소비하지만 새로운 기능을 디버깅하고 개발하는 데 훨씬 적은 시간이 걸림

BDD(Behavior Driven Development)

정의

소프트웨어 개발에서 몇 가지 일반적인 낭비 활동을 줄이는 것을 목표로 하는 일련의 개발 관행

목표

개발자, 테스터 제품 관리자 및 비즈니스 분석가와 같은 이해 관계자 간의 협업을 향상

Given-When-Then 스타일

특정 값이 주어지고(Given)
어떤 이벤트가 발생했을 때(When)
그에 대한 결과를 보장해야 한다(Then)

Given I am on the home page
When I enter my username "myeamil@gmail.com"
And I enter my password "mypassword"
Then I should see my eamil "myemail@gmail.com" on the dashboard

자연스럽게 읽을 수 있는 언어 (Gherkins)를 사용하여 이해할 수 있는 테스트를 설명합니다

장점

커뮤니케이션
- 소프트웨어 개발은 엔지니어나 개발자만을 위한것이 아님. 양질의 의사 소통을 하는 모든 과정이 처음부터 프로세스 전체에 걸쳐 진행됨
높은 가시성
- 모두가 이해하는 간단한 언어를 사용하여 모든 사람이 프로젝트 진행 상황에 대한 강력한 가시성을 얻음
최종 사용자 만족도
- 비즈니스 요구에 중점을 두면 사용자의 만족감을 얻게 됨

BDD == TDD ?

구분	TDD	BDD
테스트 디자인	- 실제 코드 작성 전에 테스트 작성 - 버그 방지, 기능, 사례 누락 방지 - 테스트 범위 측면에서 달성 할 계획 문서화
테스트 관점	[테스트 중심] - 개발자 - BDD에 비해 출력이 중요하지 않음	[행동 중심] - 최종 사용자 - GIVEN 조건 하에서 출력이 정확해야 함
의사소통 및 피드백	- 숙련된 프로그래머만 테스트를 이해할 수 있음 - 정확한 동작을 지정하는 기능이 부족하나 소프트웨어 코드를 사용하면 더 높은 품질을 얻을 수 있음	- 고객관점에서 테스트를 이해하고 더 빨리 피드백을 보낼 수 있음 - 단순하고 설명적인 영어로 작성