TDD를 사용하는 것이 좋을까?

TDD

TDD란 무엇인가

• Test-Driven Development : 테스트가 코드 작성을 주도하는 개발방식

TDD란 소프트웨어 개발 방법론 중 하나로, 테스트가 코드 작성을 주도하는 개발방식 입니다. 개발 → 테스트 방식이 아닌, 테스트 → 개발 방식의 프로그램 방법입니다. TDD 매우 짧은 개발 사이클의 반복에 의존하는 소프트웨어 개발 프로세스 입니다.

TDD 개발 방법

• 테스트 케이스 작성
• 테스트 케이스를 통과하는 코드작성
• 작성한 코드 리팩토링

먼저 개발자는 요구되는 새로운 기능에 대한 자동화된 테스트 코드를 작성하고 해당 테스트를 통과하기 위한 코드를 개발합니다. 일단 테스트를 통과하는 코드를 작성하고 상황에 맞게 리팩토링하는 과정을 거치게 됩니다.

TDD 장점

• 객체 지향적인 코드 개발
• 설계 수정시간 단축

TDD는 코드의 재사용 보장을 명시합니다. TDD를 통한 소프트웨어 개발 시 기능별로 모듈화가 이루어집니다. 의존성과 종속성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하는 것이죠. 기존적으로 단위 테스트 기반의 테스트 코드를 작성하기 때문에, 문제가 생겼을때 모듈별 테스트를 통해 문제점을 쉽게 찾는 것이 가능합니다.

또한, 테스트코드를 먼저 작성하기 때문에 입출력 구조와 기능의 정의를 명확하게 하므로 설계의 구조적 문제를 바로 찾아낼 수 있다는 장점이 있습니다.

TDD에 대한 생각들

실제 개발자들의 의견을 모아

개발자마다 TDD에 대한 의견은 여러가지입니다. 고객의 요구사항이 변경되면 또 죽은코드가 발생할텐데 필요없지 않을까? TDD가 아니더라도 단위테스트-통합 테스트-시스템 테스트 등의 프로세스를 거치게 될텐데 굳이 테스트 코드가 필요할까? 등의 질문들이 개발자를 따라다니게됩니다. 이는 시간대비 효율성이 좋지 않다라는 결론을 개발자가 내리게 만들죠.

개발자들의 TDDDP 대한 여러가지의 의견들 중에 동의하면서도 생각이 많아지는 의견들을 몇 개 인용해봤습니다.

개발자로서 만드는 코드들이 좀 더 좋은 코드가 되기 위한 개발자의 선택지 중에 하나다

TDD는 개발자들에겐 하나의 ‘숙제’보단 ‘선택’이다 라고 말해주는 것 같은 문장이었습니다. 개발자는 TDD를 통해 코드에 대한 요구사항을 명확히하고 좀 더 신뢰성있는 코드를 짤 수 있습니다. 내가 내 코드에 대해 품질을 더욱 높이기 위해서 어떤 방법을 써야할까? 에 대한 질문에 대해 TDD라는 방법도 하나 있는 것이구나라는 생각이 들더군요. 실제로 TDD를 통해 품질을 높이기 위한 개발자로서의 자신의 무기를 가질 수 있었다 라는 다른 개발자의 경험담을 들으면서 단순히 ‘TDD를 써야 좋은 코드다’ 라는 생각에서 ‘내가 TDD를 쓰다면 왜 쓰는 것일까’ 라는 생각을 한번 해보게 된 것 같습니다.

테스트는 본질적으로 우리가 흔히 작성하던 코드와 별반 다르지 않다

잘 작동하는지 확인하기 위해 제품에 직접 삽입하던 로그를 단순히 제품 밖으로 분리하는 것, 눈으로 확인하던 로그를 코드로 확인하는 것. break point를 걸어서 디버깅 하던 것을 코드로 하는 것, 빌드를 자동화 처럼 테스트를 자동화 하는 것, 개발자로서 우리가 늘상 하던 작업과 TDD는 별반 다르지 않다는 것이라는 의견에 매우 공감이 갔습니다.

TDD는 자기자신과의 싸움이다

개발 문화에서 성숙도가 부족하면 좋은 이론도 그냥 이론으로 치부되는 현실이 존재하는 것 같다는 글을 본 적이 있습니다다. 이런 문화 속에서 내가 하나의 이론을 실제로 사용해보고 적용하는 것은 자기 자신과의 싸움이 될 것입니다. 비단 TDD뿐만 아니더라도 개발에 있어서 새로운 기술의 적용은 자기 자신과의 싸움으로 이어지는 것 같습니다. “자기 자신과의 싸움에서 승리하면 그 가치를 인정하는 사람들이 생기고, 점차 단위 테스트의 중요성을 인식하리라 생각합니다.” 라는 다른 개발자의 말도 덧붙여 다가왔던 말이었습니다.

개인적인 경험과 생각

테스트 디렉터리 안에 들어가면 반기는 것은 빈 파일 뿐

Spring으로 프로젝트를 진행한 적이 있는데, 분명 이전에 이론으로 배울 때는 ‘JUnit’ 테스트 프레임워크를 사용한 TDD를 진행했지만 실제 프로젝트를 들어가니 구현하기 급급했고 테스트는 Postman을 사용해 API 테스트 위주로 많이 했었습니다. 그래서 Test 디렉터리에 들어가면 썰렁한 디렉터리만이 반겨주고 있죠. 단순히 내 개발 실력 부족으로 인한 기간 내 따라가지 못해 생기는 문제인 줄 알았는데, TDD를 따로 찾아보면서 실제로 많은 곳에서 TDD에 대해서 많은 이야기들이 나오고 있다는 것을 알게 되었습니다.

💡 TDD를 선택할 수 있는 개발자가 될 수 있도록

알지 못해 쓰지 못하는 것과 알지만 쓰지 않는 것은 다르다고 생각합니다. 이전에는 TDD가 정확히 무엇인지 몰랐고 어떻게 프로젝트에 적용 해야하는지 잘 몰랐는데 실제로 찾아보면서 무엇인지, 실제 개발자들은 TDD를 어떻게 생각하고 어떻게 사용하는지 알게 되면서 TDD를 ‘선택’할 수 있게 된 것 같습니다.

그리고 한 번 더 개발에 있어 이상과 실무는 조금 거리가 있다는 점을 느꼈고, 그 속에서 나는 어떤 선택을 해야하고 어떤 개발자고 되고싶은지에 대해 한번 더 생각해보게 된 계기였습니다.