-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Dabi edited this page Feb 5, 2022
·
4 revisions
“ 중복이 사라지기 전에는 집에 가지 말아라 ” 켄트 백 / Test-Driven Develpment 5장, 73P
- 책내용을 읽고 기억해야할 메세지 위주로 BookReview를 작성하였습니다. 표기는 M1,M2...와 같은 방식으로 하였습니다.
- 목차가 직관적이지 않기에 목차를 재편성하여, BookReview를 다시 읽어보는 것으로 책의 내용을 되새길 수 있도록 정리합니다.
-
저자의 글
M1. 테스트 주도 개발의 궁극적 목표
M2. 테스트 주도 개발의 규칙
-
1부 . 화폐 예제
M3. 테스트 목록 만들기와 목록 추가
M4. Green과 Refactoring의 차이
M5. RED → Green → Refactoring VS RED → Refactoring
M6. 불필요한 구현을 제거하는법
M7. 거시적 설계 아이디어의 파편화
M8. Delete Test
→ 작동하는 깔끔한 코드를 지향한다.
1.예측가능한 개발 방법이며, 버그에 대하여 걱정하지 않고 일의 종료시점을 알 수 있게 해준다.
2.코드가 가르쳐주는 모든 교훈을 학습할 기회를 갖게 해준다.
3.작성과 수정 보완의 이유목적이 명쾌해지고, 코드의 재사용성과 가독성이 좋아진다(같이 일하는 사람이 보기에도).
4.코드작성이 재미있어진다.
- 테스트가 실패할 경우에만 새로운 코드를 작성한다.
- 중복을 제거한다.
테스트 주도 개발의 규칙은 매우 Simple 합니다. 두가지 규칙에 해당할 때만 새로운 코드를 작성합니다.
캔트는 이러한 규칙으로 인해 발생하는 함의를 다음과 같이 정의 하였습니다.
- 매번의 결정사항에 대하여 피드백을 제공하는 실행 가능한 코드를 기반으로 하는 유기적인 설계를 한다.
- 직접 자동화된 테스트를 작성한다.
- 작은 변화에도 빠르게 대응하고, 응집도는 높고 결합도는 낮은 컴포넌트단위로 구성되게끔 설계한다.
🔴 RED - 실패하는 작은 테스트를 작성합니다. 처음에는 컴파일조차 되지 않을 수 있습니다.
🟢 GREEN - 최대한 빠르게 테스트가 통과하게끔 만듭니다. 이를 위해 Copy&Paste를 사용할지라도 괜찮습니다.
✅ Refactoring - 테스트만 통과하게끔 만든 와중에 생긴 모든 중복을 제거합니다.
기대 효과
- 결함 밀도를 낮춘다면, QA를 수동적인 작업에서 능동적인 작업으로 전환할 수 있다.
- 개발과정에서 고객의 서비스사용에 대한 피드백에 대하여 빠른 반영이 가능하다.
- 개발자들간의 분단위 협력이 가능하게끔해준다.
- 결함밀도가 낮아지기 때문에 선적가능한 소프트웨어를 유지할 수 있다.
- 만들고자 하는 프로그램에 대하여 테스트 목록(ToDoList)을 만든다.
- 모든 테스트에 대하여 한번에 처리하지않고 하나의 테스트를 통과( 중복제거 및 객체지향화)
- 새로 발견되는 문제점과 이후의 과정에 ToDoList에 추가
- RED에서 바로 Refactoring까지 완성된 코드를 작성하는 것은 세부적으로 명확한 코드를 작성해 나가는 중에 나무를 심느라 숲의 모습을 잊어버리듯이, 시간이 오래 소요되거나, 방향성을 놓치게될 수 있다.
- 따라서 가짜로 구현하기(Green)의 과정을 통해 우선 적으로 테스트가 통과하게끔 구상하고,
- 이후 명백히 구현해나가는 과정(Refactoring)을 통해 코드를 개선한다.
- 바로 구현하던 것을 TDD화 시킬경우 디자인 패턴이 지니고 있던 숨겨진 과정들을 드러나게 해준다.
- 추후에 숨겨져있던 과정이 필요하게 될 경우, 능동적인 유지보수가 가능하다.
- 테스트 과정에서 테스트코드 또한 중복을 피하고 객체지향화 해나가는 과정에서 개발 과정의 단위화가 더 명확하게 이루어진다.
- 해당 단위 들에 대하여 가시성이 뚜렷해진다.
- 주어진 상황에 필요한 작업을 구조화 순서도등을 활용하여 구조화 시킨다.
- 상/하위 클래스및 인터페이스를 구조화하며, 이에 대하여 테스트코드와 구현코드 내에서 불필요한 중복을 제거한다.
- 느낀점 : 테스트 단위를 명확하게 뜯어서 안배하고, 테스트 단위가 감이 오지않을때는 그림을 그려서 구조화 작업을 거친다.
- 테스트를 하며 발생하는 문제를 다시금 TDD Cycle에 집어넣는다.
- 코드 효율성 증대, 코드의 중복 제거등을 위해 하나의 단계에서 수행해야할 사안들이 복합적이고 여러가지라면,
- 이를 구현하는 과정또한 복합적이고 여러가지 단위를 한번에 다루게된다.
- 코드가 완성되면 추후 유지보수 또한 복합적으로 이루어져야하므로 시간과 비용이 많이 소모된다.
- 이를 파편화시켜, 최소 단위화 시키고, 가장 작은 단위의 Cycle을 돌리면 다음 해결해야할 과제들을 발견할 수 있게된다.
- 해당 사안들을 다시 ToDoList에 넣고 Cycle을 돌린다.
- 느낀점 : 실제 개발에서는 해야할 일들의 우선순위와, 중요도에 차이가 있을 것이므로 선택적으로 적당히 파편화하고
1. 시급성과 중요도가 가장 높은 작업
2. 시급성이 높은 작업
3. 중요도가 높은 작업
4. 나머지 작업순으로 작업을 처리한다.
TDD Cycle을 돌리는 과정에서 소스 구조가 변화함에 따라 필요없게 된 테스트 코드는 제거한다.