TDD 공부 시작
최근 회사에서 안드로이드 F/W의 모듈 추가와 수정을 하면서 단위 테스트가 필요한 경우가 많았다.
TDD라는 말이 그 전부터도 한참 많이 들어왔던 단어인데, 최근들어 공부해야 겠다는 생각이 들었다.
결국 단위 모듈 테스트라면 파이썬에선 __main__으로 되는 것 아닌가 싶기도 한데..
켄트 백이 쓴 Test-Driven Development: By Example을 번역한 책을 기준으로 TDD 공부를 시작하였다.
이 책은 예제를 위주로 다루고 있고, chapter에 따른 내용들은 내 맘대로 이름을 붙여 정리해보았다.
TDD
테스트 주도 개발은 단순한 두 가지 규칙만을 따른다.
- 오직 자동화된 테스트가 실패한 경우에만 새로운 코드를 작성한다.
- 중복을 제거한다.
위 규칙들에서 아래와 같은 함의를 갖는다.
- 매 결정사항에 대해 피드백을 제공하는 실행 가능한 코드를 기반으로 하는 유기적인 설계를 해야한다.
- 직접 테스트를 작성한다.
- 개발 환경은 작은 변화에도 빠르게 반응할 수 있어야 한다1.
- 쉬운 테스트를 위해 응집도는 높고 결합도는 낮은 컴포넌트들로 구성되게 설계해야 한다2.
프로그래밍 순서
- 실패하는 작은 테스트를 작성한다. 처음에는 컴파일조차 되지 않을 수 있다.
- 빨리 테스트가 통과하게끔 만든다. 코드가 개판이어도 좋다.
- 리팩토링을 통해 테스트를 통과하게 만든 문제들을 제거한다.
이런 코드 방식으로 다음과 같은 함의를 가질 수 있다.
- 결함을 감소시켜 품질보증을 능동적으로 할 수 있다.
- 고약한 예외 상황의 숫자를 충분히 낮출 수 있다면 프로젝트 매니저가 정확히 추정하여 고객을 매일의 개발 과정에 참여시킬 수 있다3.
- 깔끔하고 쉽게 이해가능한 코드로 기술적인 대화가 분명해질 수 있다면 협력하기 더 쉬워질 것이다.
TDD가 필요한 이유
용기를 주기 때문이다.
불확실함으로 인한 두려움은 망설이게하고 / 커뮤니케이션을 줄이고 / 피드백을 피하게 한다.
불학실함을 이기고 구체적인 학습을 통해 분명하게 커뮤니케이션하고/ 구체적인 피드백을 받아야 한다.
TDD를 하는 것은 톱니바퀴를 만드는 것과 같고, 하나가 작동하면 걔는 영원히 작동하는 것이다.
TDD란 프로그래밍 중 내린 결정과 그 결정에 대한 비드백 사이의 간격을 인지하고, 이 간격을 통제할 수 있게 해주는 기술이다.
결국 TDD는, 단순하게 시작하고, 자동화된 테스트를 만들고, 새로운 설계에 대한 도입을 위해 리팩토링 하는 것이다.