코드와 테스트를 동시에 작성하는 TDD(Test-Driven Development)가 언제나 프로젝트의 품질을 향상시키는 것은 아니지만, 개발자가 버그를 해결하고 코드를 리팩토링할 때 적은 비용과 빠른 시간에 작업을 마칠 수 있게 도움을 주는 건 사실이다.
테스트 작성은 그만큼 시간이 필요한 작업이지만, 장기적인 관점에서 보면 프로젝트를 올바른 방향으로 성장시키는 가장 좋은 방법이다. 물론 테스트를 잘못 만들어서 기대한 결과를 못 얻거나, 유지 보수가 어렵고 실행 시간이 너무 긴 테스트를 만들 가능성도 얼마든지 있다.
소프트웨어 업계는 오랫동안 TDD의 장점에 관해 논쟁해왔고, 대부분의 연구 보고서들은 TDD가 장기적으로 비용은 감소시키며, 품질은 향상시킨다고 결론지었다.
테스트 작성은 설계한 API가 올바로 동작하는지, 코드가 유기적으로 잘 들어맞는지 살피면서 전체 코드에 대한 안목을 키울 수 있는 훌륭한 방법이다. 또한 팀 구성원의 변화가 있을 때 테스트는 정확한 정보를 제공한다. 문서와 다르게 테스트는 현재 버전의 코드가 항상 반영되어 있다.
문서화는 유지 보수가 어렵고 작성하는 데 시간이 많이 걸리지만, 여전히 프로젝트의 중요한 부분이다. 소프트웨어 사용자나 새로 합류한 팀원이 맨 처음 보는 것이 문서이다.
전담 인력이 없다면 코드 변경과 때맞춰 업데이트되는 프로젝트 문서를 찾아보기 힘들다. 문서에 나온 예제 코드를 따라 했지만, 제대로 실행되지 않아 좌절한 경험은 누구나 있을 것이다. 이런 상황을 해결하려면 문서 내의 코드를 뽑아내어 테스트의 일부로 만드는 것이 좋다.
테스트 및 문서화에 관련된 황금 법칙이 있다. 바로 “프로젝트의 테스트, 문서화 및 코딩은 연달아 발생해야 한다.”는 것이다. 즉, 코드가 변경된 순간에 테스트와 문서에 그 변경 내용이 곧바로 반영되어야 한다는 뜻이다.
3장에서는 플라스크로 마이크로서비스를 개발할 때 사용 가능한 테스트 및 문서화 도구를 알아본다. 그리고 인기 있는 온라인 서비스를 활용해 지속적인 통합(CI; Continuous Integration)을 구성하는 방법도 배운다.
3장에서 다루는 내용은 다음과 같다.