TDD
TDD란?
TDD는 Test-Driven Development의 약어로 테스트 주도 개발이다. 소프트웨어를 개발할 때 자동화된 테스트 케이스를 작성하고 해당 테스트를 통과하는 가장 간단한 코드를 작성한다. 테스트를 통과하는 코드를 우선적으로 작성 후 필요에 맞게 리팩토링하는 과정을 거치는 것이다. 말 그대로 테스트가 코드 작성을 주도하는 개발 방식인 것이다.
즉, 개발 시에 필요한 기능을 위한 테스트 케이스를 만들고 그 테스트를 통과하기 위한 최소한의 코드를 작성하는데, 테스트를 통과하더라도 그 코드를 바로 사용하지 않고 필요에 맞게 리팩토링하는 개발 방식이다.
TDD 방식의 이점
-
개발자의 기능과 코드 이해도, 집중도 도움: 테스트 코드를 작성하는 과정에서 개발자는 테스트를 작성하기 위해 코드가 어떻게 동작해야 하는지 명확하게 이해하고, 요구사항에 대한 이해도를 높일 수 있다는 이점이 있다.
-
테스트 코드 작성의 중요성: 어떤 기능을 새로 추가하면 잘 작동하던 이전의 기능이 제대로 작동하지 않는 경우가 발생할 수 있다. 심지어 개발자가 이를 인지하지 못하는 경우 더 심각해질 수 있다. 이러한 경우를 방지하기 위해서라도 테스트 코드를 작성하는 것이다. 새로운 기능을 추가할 때 테스트 코드를 작성함으로써, 새로운 기능 테스트와 동시에 기존의 기능들 또한 잘 작동하는지테스트를 통해 확인 할 수 있다는 점이다.
-
좋은 코드로 작성 도움: 코드를 작성할 때 가독성을 위한 coding convention, 비즈니스 로직, 예외처리 부분 등과 더불어 디버깅을 하다보면 사용하지 않는 dead code 등으로 인해 코드가 방대해진다. 이 때 TDD 방식을 해왔다면, 테스트 코드가 그 중심을 잡아줄 수 있기 때문에 리팩토링 속도와 코드의 퀄리티가 그만큼 향상될 수 있다.
TDD 방식의 이의
Q. 코드 생산성에 문제가 있을 수 있지 않나?
일단 테스트 코드를 작성한다는 부분부터 작성해야할 코드가 늘어난다는 점이다. 테스트 코드 외에도 여러가지 코드 작성 및 신경 써야 할 부분이 있을 것인데 추가적으로 케이스 작성까지 한다면 퀄리티보다 빠른 생산성이 요구되는 환경에서는 TDD는 큰 부담이 될 수 있다.
Q. 테스트 코드를 작성하기 쉬운가?
TDD 방식의 이점 중 하나인 개발자의 기능의 요구사항에 대한 이해도를 높일 수 있다는 점이 있는데, 이 뜻은 다르게 보면 그만큼의 이해도를 얻기 위해 정확히 파악하고 학습을 하는 등 시간을 들여야 한다. 또한 개발은 혼자가 아닌 팀 단위로 수행하기 때문에 팀원 전체가 이 방식을 동의하고 익숙해져야 프로젝트의 테스트 코드로써 역할을 할 수 있게 되는 것이다.
Q. 테스트 코드를 모든 상황에 대해서 작성을 할 수 있고 작성해야 하는가?
당연히 예상치 못했던 예외 케이스가 발생할 수 있다. 만약 테스트 코드 작성 중 어려움이 발생했고, 그러한 상황 때문에 실제 코드가 중심이 되지 않고 테스트를 위해 구조 변경이 필요한가라는 고민을 할 수도 있다. 이처럼 본질인 실제 코드보다 테스트 코드가 더 방대해지면 코드를 관리하는 것도 쉽지 않을 것이다.
결론적으로
TDD방식은 무조건적으로 사용할 필요는 없다. 왜냐하면 테스트 코드는 모든 코드에 대해서 작성할 수 없으며, 작성할 필요도 없다. 또한 테스트 코드는 완벽하지 않다. 테스트 코드를 작성한다고 버그가 발생하지 않지도 않기 때문이다. 애초에 TDD는 100% coverage와 100% 무결성을 주장하지 않았다.