테스트 주도 개발(Test-Driven Development, TDD) - 1
테스트 주도 개발(Test-Driven Development, TDD)에 대한 학습
참고 - 아름다운 코드와 즐거운 개발을 위한 테스트 주도 개발 | 켄트백 저
테스트 주도 개발
엔터프라이즈급 개발 환경에선 새로운 기능을 하나 추가하거나 수정하면
온갖 자잘하거나 크리티컬한 에러가 연쇄적으로 발생할 가능성이 매우 높다.
이는 각 코드가 서로 독립적이지 않으면서 단위별로 완벽하게 검증되지 않은 상태이기 때문에 발생한다.
그리고 이런 연쇄적인 에러는 코드를 유지보수 하는 개발자에게 두려움을 심어준다.
TDD는 개발자가 용기를 가질 수 있게 해 준다 그래서 두려움을 관리하는 방법이다.
물론 단위 테스트(Unit Test)를 진행하여 각 코드를 검증했다고 하더라도 이러한 에러는 분명 발생할 수 밖에 없겠지만,
그나마 에러 발생 빈도를 최저치까지 끌어내릴 수는 있을 것이다.
TDD란 테스트 코드 자체를 하나의 요구사항 명세서로서 쓰는 것과도 같다.
일반적으로 우리는 프로그램을 개발할 때 아래와 같은 순서로 진행한다.
코드를 작성한다
서버를 올린다
코드가 제대로 동작하는지 확인한다
에러가 발생하면 서버를 내린다
1~4를 반복한다
우선 서버를 올렸다 내렸다 하는 부분에서 시간적인 비용의 손해가 많이 발생한다.
이러한 시간 지연은 개발자를 조급하게 만들고(결과물을 빨리 확인하고 싶기에),
이런 조급함은 완벽한 테스트를 하기 힘들게 만들 가능성이 높다.
그렇다면 TDD를 적용한 경우에는 어떻게 개발을 진행할까?
켄트 백은 이를 레드-그린 사이클(Red-Green Cycle)이라고 말했다.
빨강(Red) - 실패하는 작은 테스트를 작성한다. 처음에는 컴파일조차 되지 않을 수 있다
초록(Green) - 빨리 테스트가 통과하게끔 코드를 작성한다. 이를 위해 어떤 죄악을 저질러도 좋다
리팩토링(Refactoring) - 일단 테스트를 통과하게만 하는 와중에 생겨난 모든 나쁜 냄새(Bad Smell)를 제거한다.
💡 죄악 : 기존 코드 복사해서 붙이기(Copy & Paste), 테스트만 간신히 통과할 수 있게 함수가 상수를 반환하도록 구현하기 등의 편법들
💡 나쁜 냄새(Bad Smell) : 리팩토링(Refactoring) - 마틴 파울러를 읽어보자. 명저서이다. 일반적으론 중복되는 코드를 말한다.
TDD의 장점으로 빠른 피드백(Feedback)이 있겠다.
대부분의 과정을 자동화하여 테스트 코드만 실행한다면 결과물을 즉시 확인할 수 있기때문이다.
그리고 이렇게 테스트 코드를 먼저 작성하고 해당 테스트 코드를 통과해낸 코드는 소위 말하는 검증된 코드라고 볼 수 있다.
여기서 중요한 것은 우리는 개발자로서 코드를 작성할 때
무의식적으로 통과되게끔 코드를 작성할 가능성이 높기 때문에 무조건 실패할 수밖에 없는 테스트 코드를 작성하라는 것이다.
켄트 백은 이 TDD가 보안 소프트웨어와 동시성 프로그램을 제외한 대부분의 코드를
완벽에 가깝게 검증해줄 수 있는 방식이라고 설명하고 있다.
우선 어려운 용어는 다 제쳐두고 위의 일반적인 개발 방식의 1~5의 과정을 직접 반복하지 않아도
모두 자동화하여 결과물을 즉시 볼 수 있다는 점에서 매우 큰 메리트가 느껴진다.
