[개발 상식] TDD
2018. 8. 22. 17:52ㆍCS/개발 상식
반응형
해당 시리즈는 Interview_Question_for_Beginner를 기반으로 추가 학습을 진행해 작성하였습니다.
목차
TDD
(Test-Driven Development)
매우 짧은 개발 사이클의 반복에 의존하는 소프트웨어 개발 프로세스로, 테스트가 코드 작성을 주도하는 개발방식
TDD 개발 순서
- 개발자는 요구되는 새로운 기능에 대한 자동화된 테스트케이스를 작성
- 해당 테스트를 통과하는 가장 간단한 코드를 작성
- 상황에 맞게 리팩토링하는 과정을 거침
TDD의 특징 (장점)
- Add a test
요구사항에 집중한 코드 구현 가능
- 새로운 기능을 추가하기 전 테스트를 먼저 작성
- 테스트 작성을 위해선 해당 기능의 요구사항과 명세를 분명히 이해해야 함
- 사용자 케이스, 사용자 스토리 등
- Run all tests and see if new one fails
새 기능을 추가할 때 발생할 수 있는 문제를 방지
- 새로운 기능을 추가할 때 테스트 코드를 작성하여 새 기능 및 기존 기능들이 제대로 작동하는지 확인 가능
- 새 기능 추가 시 기존 기능이 제대로 작동되지 않고, 이를 인지하지 못하는 경우를 방지함
- Refactor code
리팩토링 할 때 좋음
- 리팩토링의 필요성
- 고려해야 할 요소(가독성, 일관성, 확장성 등)가 너무 많아 ‘좋은 코드’를 작성하기 어려움
- 방대해진 코드에 대해 리팩토링 하게 됨
- 리팩토링 할 때 테스트코드가 있으면 좋은가?
- 어차피 제대로 작동하는지 판단해야 하는 시점은 옴 & 테스트에 관한 문서를 만들어야 함 => 테스트 코드가 자동으로 해줌
- 리팩토링에 있어 테스트코드의 역할
- 제대로된 기능을 하고 있는지 자동으로 수행해줌
- ex) 함수 분할 시 목표 수행 기능 테스트 가능
- 리팩토링 속도 향상
- 코드 퀄리티 향상
- 객체지향적이고 확장 가능한 용이한 코드
- 재설계의 시간을 단축 시킬 수 있는 코드
- 디버깅 시간이 단축되는 코드
- 제대로된 기능을 하고 있는지 자동으로 수행해줌
- 리팩토링의 필요성
TDD의 의문점들 (TDD를 사용하므로써 생길 수 있는 문제들)
Q1. 코드 생산성에 문제가 있지 않나?
개발에 앞서 테스트 코드까지 작성하므로써 많은 시간이 소요될 수 있다.
- 코드량이 늘어남
- 코드 퀄리티 보다 빠른 생산성이 요구되는 시점에서 큰 걸림돌이 될 수 있음
Q2. 테스트 코드를 작성하기가 쉬운가?
높은 진입장벽으로 TDD를 적용시키기 어렵다.
- TDD 방법, 범위, 프레임워크 종류에 대한 학습 필요
- 팀 단위의 개발에 있어 모두의 동의 및 지식 필요
Q3. 모든 상황에 대해서 테스트 코드를 작성할 수 있는가? 작성해야 하는가?
모든 코드에 대해 테스트 코드를 작성할 수 없다.
- 다양한 사용자, 생각지도 못한 예외 케이스 존재
- 실제코드보다 테스트에 집중되는 주객전도 현상 발생할 수 있음
Reference
반응형