[20.10.03] TDD에 대한 간단한 고찰

TDD란, Test Driven Development 의 약자로서 예상 케이스에 대비한 테스트를 기반으로 점진적으로 코드를 수정하고 개발해나가는 방식이다. 라 피신 때 정신 없이 과제를 수행하고 평가를 진행했을 당시, 친절한 누군가의 간이 테스트 코드로 인해 클러스터 내의 적지 않은 사람들이 동료 평가, 몰리네뜨의 채점 전에 스스로 오류를 파악하고 그에 맞는 예외처리를 추가해주며 코드의 완결성을 더욱 높일 수 있었다.

 

그 덕에 ‘프로그램을 만들고 코드를 짤 때, 그 코드를 검증해줄 테스트 코드는 꼭 필요하겠구나.’ 라는 생각을 가질 수 있었고 이번 본 과정의 첫 프로젝트인 libft 를 만드는 기간 동안 해외의 기존 카뎃들이 업로드 해놓은 3 개의 테스터와 함께 했다. 그러다 문득, 나는 계속 코드를 고치고 테스터는 계속 해서 오류를 뱉어대는 시간이 길어지면 길어질수록 속에서는 뭔가 이질감이 들었던 것 같다.

 

‘이렇게까지 해야 하나..?’

 

TDD 방법론에 대해서 반대하는 입장에서 가장 많이 거론되는 부분은 ‘코드를 검증하기 위해 테스트 코드를 짰는데, 테스트 코드를 검증하는 테스트 코드는 필요가 없냐’ 라는 부분이었고 결국 테스터도 사람이 만드는 것이기에 다양한 환경에서 프로그램을 돌렸을 때 출력되는 아웃풋은 완벽하지 않을 거라는 우려 섞인 시선이었다.

 

개인적으로 그 부분에 대해서 어느 정도 힘이 실렸던 게 이번 일주일의 시간이었다. 내가 지금 별의별 짓을 다하며 고치려고 하는 이 오류 메시지가 사실은 테스트 코드 자체의 오류라면? 혹은 여기서 pass를 받은 로직이 실제 채점에서는 (현업에서는 실제 사용자의 case 들) 정반대의 결과를 도출한다면? 회의적인 생각이 들었지만, 그럼에도 불구하고 테스트는 필요하다는 사실은 부정할 수 없었다. 다만 본인이 만들었건, 다른 누군가가 만들었건 테스트 코드 자체를 맹신하며 코드를 짜는 것만큼은 지양해야할 필요가 있다고 느낀다.

 

아마 다음 과제는 ft_printf 가 될 텐데, 프로젝트를 진행하는 순서를 조금 바꿔볼 생각이다. 최대한 subject 페이지에서 요구하는 사항과 컨벤션을 이해하고 대입할 수 있는 테스트 코드를 먼저 찾아낸 후에 점진적으로 코드의 양을 늘려가며 예상할 수 있는 케이스들을 메꿔나갈 것이다. 그 과정에서 오류가 발생했을 때는, 항상 여러 방면에서 일어날 수 있는 오류라고 생각하며 굳어있는 사고는 하지 말자.