WHAT ?
TDD란?
테스트 주도 개발(Test-driven development TDD)은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. 개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다. 이 기법을 개발했거나 '재발견' 한 것으로 인정되는 Kent Beck은 2003년에 TDD가 단순한 설계를 장려하고 자신감을 불어넣어준다고 말하였다.
- 위키백과 -
- 테스트 주도 개발(Test-driven development, TDD)은 매우 짧은 개발 사이클을 반복하는 SW개발 프로세스 중 하나이다.
- 짧은 개발 주기의 반복에 의존하는 개발 프로세스이며, 애자일 방법론 중 하나인 eXtream Programming(XP)의 'Test-First' 개념에 기반을 둔 단순한 설계를 중요시한다.
- TDD = TFD(Test-first development) + 리팩토링
- TDD는 단순한 설계를 장려하고, 자신감을 불어 넣어준다.
- 여러 방법론 및 패턴 축약어에 존재하는 'D'를 잘 구분할 것
- TDD는 필수로 Development 이전에 Design이 되어야한다.(설계 -> 개발)
장점
- 테스트 문서 대체가 가능하다.
- 재설계 시간이 단축된다.
- 디버깅 시간이 단축된다.
- 보다 튼튼한 객체 지향적인 코드를 작성할 수 있다.
- 추가 구현이 용이하다.
단점
- 가장 큰 단점은 생산성이 저하된다.
프로그래밍 순서
- Write a failing test
- 실패하는 작은 테스트를 작성한다.
- 컴파일조차 되지 않을 수 있다.
- Make the test pass
- 어떻게든 테스트를 통과할 수 있도록 만든다.
- 어떤 '죄악'을 저질러도 상관없다.
- Refactor
- 2번 과정을 통해 생겨난 '죄악'들을 제거한다.
원칙
- 실패하는 단위테스트를 작성할 때까지 구현코드를 작성하지 않는다.
- 컴파일은 실패하지 않으면서, 실행이 실패하는 정도로만 단위테스트를 작성한다.
- 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
용기
- TDD는 두려움을 관리하는 방법이다.
- 두려움은 망설이게 만든다.
- 커뮤니케이션을 줄인다.
- 피드백을 무서워한다.
- 문제해결을 까다롭게 만든다.
- 가능한 빨리 구체적인 학습을 시작한다.
- 분명한 커뮤니케이션과 구체적인 피드백을 찾는다.
WHY?
- 그래서, 이걸 꼭 해야하냐? 현업에서 모두 이 방법론을 사용하냐? -> 그렇지 않다
- 앞서 얘기했듯, 'TDD'는 하나의 '방법론'일 뿐이며, 적재적소에 사용해야 한다.
- '애자일(Agile, 기민한/민첩한)'이란 용어는 소프트웨어 개발 방식의 하나로, 작업 계획을 짧은 단위로 세우고 제품을 만들고 고쳐 나가는 사이클을 반복함으로써 고객의 요구 변화에 유연하고도 신속하게 대응하는 개발 방법론이다.
- 그렇다면, 적재적소란 언제일까?
- TDD는, '애자일'에 기반한 '방법론'이다.
- 아무것도 보이지 않는 캄캄한 숲속에서, 우리는 조금씩 이동한다.
- 조금씩 이동하며, 동료와 함께, 방향수정 및 주위사물인지 등 피드백과 협력이 이루어진다.
- 이러한 과정을 반복하며, 우리는 불확실성에서 점차 확실성의 영역을 확보한다.
- TDD도 마찬가지로 짧은 단위의 개발을 반복하며, ‘피드백’과 ‘협력’을 증진시키는 것이기 때문에 불확실성이 높을 때 도움이 되는 것이다.
HOW?
막막한 상태에 놓여라
- 요구사항 분석 및 설계
- 객체를 추출해본다.
- UI, Model과 의존되어있지 않은 Domain 영역을 집중 설계한다.
- MVC에서의 Controller 등 도메인 테스트
- Domain 객체 설계하기
- 기능 목록 작성
아직도 막막하다면? 분리없이 일단 구현한다.
- 구현하려는 프로그래밍의 도메인 지식이 쌓인다.
- 갈아엎는다.
- 구현할 기능 목록을 작성하거나, 간단한 도메인을 다시 설계해본다.
- 기능 목록 중, 비교적 설계가 쉬운 기능부터 TDD로 구현을 시작한다.
- 복잡도가 높아져 리팩토링이 어렵다면, 다시 갈아엎는다.
- 재도전 반복
프로그래밍 순서
- 기능목록을 작성한다.
- 설계한 클래스에 맞는 테스트 클래스 파일 생성한다.
- 최대한 컴파일이 되는 레드사이클을 구현한다.
- 클래스 생성 및 임포트 등 컴파일을 통과하도록 만든다.
- 컴파일 될 때까지 빨간줄 없앤다.
- 테스트가 실패한다? 그럼 이제 그린단계 시작이다.
- 이제 테스트를 해결하기 위한 모든 '죄악'을 저지른다.
- 같은 테스트를 하나 더 만들어본다.
- 다른 함수는 실패한다.
- 그러면 둘다 통과하게하려면 어캐해야할까? 를 생각
- 이게 해결되면 다음단계로 넘어가기
- 다른 함수는 실패한다.
- 구현코드 리팩토링 진행
- 테스트코드 리팩토링 진행
'TIL' 카테고리의 다른 글
[OOP] SOLID 원칙(객체 지향 설계) (0) | 2023.02.21 |
---|---|
[OOP] 객체 지향 생활 체조 원칙 (0) | 2023.02.21 |