#TDD #BDD #TEST #Mockito #JUnit
Explanation
TDD(Test Driven Development) 테스트를 기준으로 하는 개발 방법론
BDD(Behavior Driven Development) 행동을 기준으로 하는 개발 방법론
TDD (Test Driven Development)
테스트 주도로 개발을 이끌어 나가는 것. 테스트를 먼저 작성하고 나서, 테스트가 정상적으로 돌아갈 때 까지 테스트를 하면서 코드를 작성하는 작업
원하는 작업이 제대로 돌아갈 때까지 테스트와 코드 작성을 무한대로 반복하며 개발
테스트의 종류로는
- 단위(Unit) 테스트
- 통합(Integation) 테스트
- E2E(End to End) 테스트
- 회귀(Regression) 테스트
- 성능(Performance) 테스트
장점
각 모듈의 역할이 단순해지고 명확해진다. 즉 모듈의 크기를 줄일 수 있게 되고 모듈과 계층 간의 커플링을 적게 만들어 결국 프로젝트의 유지보수와 확장을 더 쉽게 한다
- 각 모듈의 역할이 단순해지고 명확해짐
- 프로젝트의 유지보수와 확장이 쉬움
- 수동 테스트에서 시간을 단축할 수 있음
- 놓칠 수 있는 것들을 반복 테스트하기 좋음
- 프로젝트의 품질을 높이고, 효율적인 테스트 경험과 사용자의 입장을 고려한 개발을 진행할 수 있도록 해줌
- 실제 사용자의 실행 환경과 거의 동일한 환경에서 테스트를 진행하기 때문에, 실제 상황에서 발생할 수 있는 에러를 사전에 발견할 수 있음
BDD (Behavior Driven Development)
테스트 케이스를 작성하는 대신 동작 작성으로 시작하는 TDD의 확장
시나리오를 기반으로 테스트 케이스를 작성하며 함수 단위 테스트를 권장하지 않는다. 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 레벨을 권장한다. 하나의 시나리오는 Given, When, Then 구조를 가지는 것을 기본 패턴으로 권장
- Feature : 테스트에 대상의 기능/책임을 명시
- Scenario : 테스트 목적에 대한 상황을 설명
- Given : 시나리오 진행에 필요한 값 설정
- When : 시나리오 진행 시 필요한 조건 명시
- Then : 시나리오 완료 시 보장 결과 명시
테스트 대상은 A 상태에서 출발하며(Given) 어떤 상태 변화를 가했을 때(When) 기대하는 상태로 완료되어야 한다. (Then)
TDD와 BDD
BDD의 테스트케이스로 시나리오 검증을 하고, 해당 시나리오에서 사용하는 각 모듈들은 TDD의 테스트케이스로 검증을 하는 방법
Comment
개발자가 테스트 진행 시 어짜피 해당 테스트의 Exception을 고려 해서 개발하기 때문에 테스트를 해서 애플리케이션의 문제점을 찾기 보단 개발 하기 전 설계/기획을 한번 더 점검한다고 생각 됨
- 개발자가 테스트 코드를 작성해서 테스트 한다는 것 자체가 이미 다 고려해서 개발하기 떄문에 작성할 필요가 있나 싶음
