TDD(Tesst-driven Development)
TDD(Test-driven Development)는 코드를 작성하기 전에 테스트를 쓰는 소프트웨어 개발 방법론이다. 다시 말해, 개발자 자신이 바람직하다고 생각하는 코드의 결과를 미리 정의하고, 이것을 바탕으로 코드를 작성하는 법이다. TDD를 통해 소프트웨어를 개발한다는 것은 작은 단위의 테스트 케이스를 작성하고, 이를 통과하는 코드를 작성하는 과정을 반복하는 것을 의미한다.
TDD의 개발 주기를 그림으로 나타내면 아래와 같이 총 3단계로 이루어진다.
1. Write Failing Test: 실패하는 테스트 코드를 먼저 작성한다.
2. Make Test Pass: 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
3. Refactor: 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.
과정에서 1의 과정을 마치기 전에 2의 작업을 시작하지 않도록 주의해야 한다. 또한 2를 진행할 때에는, 1의 테스트를 통과할 정도의 최소 코드만 작성해야 한다. 테스트를 먼저 작성하는 것은 필연적으로 코드를 어떻게 구성할지 고민하게 된다는 것을 의미하고, 결과적으로 버그가 더 적은 코드를 짤 수 있게 된다. 또, 불필요한 설계를 피할 수 있고, 테스트 코드의 요구 사항에 집중할 수 있게 된다. 일반적으로 TDD를 따라 소프트웨어를 개발할 경우 그렇지 않은 경우보다 결함을 50 ~ 90% 까지 감소시킬 수 있다.
이처럼 버그가 적은, 보다 효과적인 코드를 짤 수 있는 방법임에도 불구하고, 실제로 완전한 TDD를 따르는 개발자는 의외로 많지 않다. 그 이유는 대부분의 개발자들이 생각하고 일하는 방식과 일치하지 않기 때문이다. 대부분의 개발자는 테스트를 작성하는 것보다, 만들어야 하는 것을 바로 코드로 작성하는 방식이 훨씬 자연스럽고 빠르다고 느낄 것이다. 많은 개발자들에게 왜 TDD를 따르지 않는지 물어보면, 대부분 ‘속도' 때문이라고 대답할 것이다.
TDD를 사용하는 이유
그럼에도 불구하고 TDD를 사용하는 이유는 무엇일까? 코드를 작성하기에 앞서 테스트 코드를 먼저 작성해야 하기 때문에 시간이 오래 걸리는 것처럼 느껴지지만, 오히려 예상하지 못했던 버그를 줄여 소요 시간을 줄일 수 있기 때문이다. 개발 과정에서 코드는 다양한 조건에 의해 계속해서 삽입, 수정, 삭제된다. 이 과정에서 코드가 중복되거나 불필요한 코드가 남게 된다. 그리고 그로 인해 여러 가지 버그가 발생하거나, 디버깅 또한 어려워지는 현상이 발생하기도 한다. 결국 그런 코드를 유지보수하기 위해서는 처음 개발할 때 아꼈던 리소스보다 더 많은 리소스를 투입해야 하는 경우가 발생한다.
지금 당장 완전한 TDD를 따르는 것은 아주 어려운 일이다. TDD 방법론에 대해 학습하되, 개발 실력을 향상시키는 것을 더 우선순위에 두어야 한다. 그러나 작성하려는 코드에 대해 특정한 규칙(테스트)을 설정하기 위해 고민하면서, 코드가 큰 틀에서 어떤 의미를 갖게 되는지 고민하는 것은 스스로를 성장시킬 수 있는 중요한 도구가 될 것이다.
테스트 코드를 작성하는 방법
지금까지 console.log를 사용하여 현재 작성한 코드가 어떤 결과물을 도출하는지 확인한 경험이 있을 것이다. console.log를 통해 확인하는 것도 일종의 테스트이다.
또, JavaScript Koans 과제를 진행하면서 테스트를 작성해 보기도 했다. 그 과정에서 describe, it, assert, expect 등의 다양한 키워드들을 마주쳤을 것이다. 이 키워드들은 JavaScript 내장 기능이 아니라 테스트 프레임워크에서 제공하는 테스트 작성을 위한 도구이다.
여러 개발자들이 더 나은 테스트를 작성하기 위해 많은 테스트 오픈소스 프레임워크를 제작했다. 이후 진행할 Test Builder 과제에서는 mocha라는 테스트 프레임워크와 chai라는 라이브러리를 사용한다.
공식문서
