Test Code는 소프트웨어 개발에서 코드의 정확성, 품질, 안정성을 검증하기 위해 사용되는 코드이다.
이는 주로 단위 테스트, 통합 테스트, 시스템 테스트 등과 관련이 있다.
TDD는 소프트웨어를 개발할 때 테스트 코드를 먼저 작성하고, 그 후에 해당 테스트를 통과시키는 싸이클을 반복하는 개발 방법론입니다.
Test Code를 작성하면 장점이 많다. 위에서 Test Code에 대한 정의처럼 코드의 정확성, 안정성에 대해 1차적으로 검증을 할 수 있다.
하지만, Test Code를 작성할 때 Test Case에 대해 많은 신경을 쓰게 된다면 의미없는 Test Code를 작성할 수 있으며 이것은 Test Code에 대한 본질적인 의미를 잃어버릴 수 있다. 즉, 주객전도가 일어날 수 있다고 생각한다.
이러한 부분은 경력이 쌓이게 된다면, 크게 신경쓸 필요없이 Test Code를 잘 작성하게 되겠지만 초보자의 입장에서는 어떠한 범위까지 테스트를 진행해야 되는 것인지 잘 몰르기 때문에 의미없는 Test Code를 작성할 확률이 매우 높아진다고 생각한다.
TDD방식으로 프로젝트의 일부 기능을 구현을 했었다. TDD 방식으로 기능구현을 하니 장점보다 단점이 워낙 많아졌다고 느낀 방식이였던 것 같았다.
TDD 방식으로 개발을 진행할려면, 모든 케이스에 대해 생각을 해야한다. 그렇다보니 PM이 작성했던 PRD를 100%를 이해한 상태에서 모든 케이스를 생각해야한다. 이것은 쉽지 않은 일이라고 생각한다. 또한 모든 케이스에 대해 생각을 하는 리소스가 많이 들어간다.
실제로, PRD를 보며 Test Case를 작성했지만 실제 로직구현을 했을 때에는 추가적인 Case들이 많아진 경험이 있다.
TDD 방식은 초기에 많은 시간이 오래 걸리게 된다. 이러한 부분을 보았을 때에는 프로젝트의 기간이 짧으면 TDD의 방식은 적합하지 않다고 생각한다. 또한, 기획 수정은 빈번하게 일어나기 때문에 기획 수정이 된다면 기존에 있던 Test Code들은 의미가 없어지게 된다.
로직을 작성하며 이 부분이 크게 와닿았던 것 같았다. 로직 작성의 에러를 고치기 위해 디버깅을 하고 Test를 실행하는 시간이 길어서 즉각적인 반응을 얻을 수 없는 것이 불편했었다.
Test 라는 것은 매우 중요하다고 생각한다. 하지만 초보자일수록 크게 해맬 수 있는 부분이고 기능을 구현하는데에 있어서 리소스가 더 많이 들어갈 수있으며 그 리소스가 의미없는 리소스일 수도 있다.
비록 의미없는 테스트를 작성을 할지라도, 이러한 경험들이 나중에 Test Code를 잘 작성하는 것에 큰 도움이 될 것이라고 생각한다.
TDD의 방식은... 아직까지도 잘 모르겠다.