제가 질문의 의도를 정확하게 이해했는지 모르겠네요. 답변이 의도와 맞지 않으면 추가 질문 주시면 좋겠습니다.

TDD는 테스트 주도로 개발하는 방식입니다. 그냥 편하게 실행 코드보다 테스트 코드를 먼저 만드는 것으로 이야기할께요. 자바 진영에서 일반적으로 TDD 도구로 JUnit을 활용합니다. JUnit을 활용하면 여러 개의 단위 테스트를 실행할 수 있습니다. 이 부분은 모두 이해하고 계시리라 생각합니다.

JUnit 기반으로 단위 테스트를 만들 수 있고, JUnit을 활용해 통합 테스트도 만들 수 있습니다. JUnit + Selenium과 같은 도구를 활용하면 Acceptance Test(통합 테스트와 비슷하다고 생각하세요.)도 구현할 수 있습니다. 이 모든 테스트를 JUnit 기반으로 구현한 후에 말씀하셨듯이 클릭 한번으로 모두 실행할 수 있습니다.

테스트 성격이 달라지기 때문에 단위 테스트, 통합 테스트(integration test), 인수 테스트(acceptance test)를 분리해서 구현한 후에 빌드하는 시점에 같이 테스트를 하는 경우가 일반적입니다. 하지만 이 같이 여러 개의 테스트를 분리해서 구현하는데 많은 비용이 발생하기 때문에 모든 테스트를 만들기 힘들고 소프트웨어 성격에 따라 테스트 구현 정도가 달라진다고 생각하시면 됩니다.

@자바지기님,

일단 좋은 내용과 의견 감사드립니다.

제가 약간 설명을 부족하게 했었는데, 팀 내에서 TDD를 통해 개발하고 각자 팀원이 개발한 테스트 코드들을 모두 모아서 단위 테스트, 통합 테스트로 묶어서 기능에 대한 테스트는 테스트 코드가 하고 화면에 있는 테스트는 화면만 간단하게 짆애하는 방식(QA가 없는 관계로)으로 하면 어떨 까해서 질문을 드렸습니다.

근데 한가지 의문점이 드는 것은 TDD가 이런식의 정상작동 테스트를 할 때, 화면과 기능을 분리한 채로 진행한 테스트가 정말로 제품의 정상작동을 제공해 줄 수 있느냐는 거였습니다,

이런식으로 기능 테스트를 코드로 자동화 시키면 좋을 것 같습니다만 이렇게 자동화된 테스트만으로 온전히 소프트웨어가 정상적으로 작동한다고 보장할 수 있는지가 궁금합니다.

@이도현 모든 테스트가 그렇듯이 모든 기능을 완벽하게 자동화할 수는 없습니다. 예를 들어 화면 UI 상의 픽셀이 맞지 않거나, 화면이 일그러지는 부분, PC웹과 모바일 웹에서 정상적으로 보이는지 등등 반드시 사람이 확인할 수 밖에 없는 부분이 있습니다.

하지만 핵심 비지니스 로직에 대해서는 테스트를 자동화할 수 있겠죠. 즉, 서비스의 글쓰기 기능이 정말 중요한데 글쓰기가 정상 동작하는지는 자동화된 테스트를 통해서 배포하기 전에 검증을 할 수 있기 때문에 큰 대형 사고는 막을 수 있겠죠.

자동화된 테스트가 필요하고 좋은 것은 사실이지만 이를 위해서는 비용이 발생합니다. 특히 화면에 대한 자동화 테스트의 경우 화면 UI가 변경되는 경우가 많으면 유지보수 비용이 많이 발생합니다. 따라서 모든 부분을 자동화하기 보다는 정말 핵심 기능에 대해서만 자동화된 테스트를 유지하는 방법도 좋은 전략이라고 생각합니다. Acceptance Test의 경우는 그렇고요. 단위 테스트의 경우에는 TDD가 습관화되어 있다면 구현 단계부터 테스트를 만들어 나가면 그 만큼의 효과는 시간이 지날 수록 나타나지 않을까 생각합니다.

TDD를 통한 단위 테스트를 만드는데 있어 중요한 점은 테스트를 만드는 것이 아니라 테스트를 만듦으로써 Production Code(실행 코드)를 지속적으로 리팩토링해 가능한 깔끔한 상태로 유지해 나가는 것에 있다고 생각합니다. TDD가 힘든 practice이지만 본인의 실력을 향상하는데도 큰 도움이 되지 않을까 생각합니다.