백엔드

TDD 방법론 이게 뭘까 ?

bumheeeee 2025. 1. 27. 03:43

 

서론

 

한 선배가 나에게 예전에 과제를 내주며 " TDD 방법론으로 정리해서 만들어봐 " 라는 말을 하셨다.

 

난 당연히 이게 뭐지? 하고 다른 블로그들을 봤는데 진짜 무슨 이야기인지 하나도 감이 안 잡혔다. ( 당시 2023년 후반 )

 

근데 요새 개발 공부를 하면서 어쩌다 TDD론을 다시 보게 되었는데 보니깐 반가운 단어길래 한 번 알아보았다.

 

이제 보니깐 어느정도 알아 듣는 이야기였고 이해가 가는 이야기였다.

 

그리고 간이 프로젝트라도 이 TDD론을 지키려고 하고 있다.

 

하지만 처음 접하면 이것을 굳이 왜하냐? 라는 생각이 든다.

 

나 또한 그랬다. 

 

근데 난 몇 년 먼저 하신 분 들이 더 잘 안다고 생각한다.

 

그래서 약간 운동 같은거라고 생각한다.

 

지금도 건강해서 굳이 운동을 왜 해야하냐?

 

나중에도 건강하기 위해서..

 

 

본론

 

TDD ( Test - Driven - Development ) 란?

 

직역하면 테스트 주도 개발.

 

테스트를 필두로 개발을 진행한다는 의미이다. 

 

TDD론은 그냥 어떤 한 이론이므로 과정을 모두 정리하고 하는 것이 아니라 과정을 따라가는 이론이라고 보면 될 것 같다.

 

테스트를 필두로 개발한다는 것은 테스트 코드를 작성하고 그 테스트를 통과하기 위해 코드를 작성해 나가는 것을 반복하는 과정이다.

 

TDD 사용을 위해 어떻게 ? 사용법

 

 

테스트 코드를 작성 후에 버그를 찾고 발전해 나가며 실제 코드를 작성 하는 것이 TDD.

 

그렇기 때문에 테스트 코드를 짜는 목적성이 확실해야 한다.

 

내가 무슨 테스트를 통과해야 필요한 코드 인지가 무엇인지를 알아야한다는 것.

 

아래는 TDD 방법론의 대표적인 사이클을 시각적으로 나타낸 것.

 

 

 

 

Fail

 

개발자가 만들려고자 하는 방식에서 테스트 코드를 작성한다. 그리고 이 테스트 코드는 전체적인 코드를 짜는 것이 아닌 오직 하나의 테스트만 통과하기 위해 만들어진 조각이기 때문에 그에 대한 버그나 실패하는 코드를 작성하는 것이다.

이 과정이 왜? 필요하냐 테스트를 하나씩 통과하는 일정의 조각을 모아서 점차 실질적인 코드를 만들기 위해서 실패하는 코드를 작성한다.

 

 

Pass

 

그럼 실패한 코드는 한 테스트를 통과하기 위해 만들어진 코드이고 전체 테스트를 돌렸을 때 실패한 것이므로, 한 테스트를 통과시킨다.

 

 

Refactor

 

케이스 한 개를 통과한 코드를 실질적으로 사용하는 코드로 발전시키기 위해 한 단계 더 나아가 테스트를 늘리며 코드의 품질을 높이기 위해서 코드를 더 발전 시킨다.

 

 

 

실질적인 코드까지 이 사이클을 반복하며 만든다.

 

TDD 방법론 왜 사용하는가?

 

 

일반적인 개발 형식은 

 

 

개발 구도 설계  > 개발 > 테스트 > 완료

 

이런 형식으로 진행되는데 이 테스트에서 만약 버그가 진행되면 코드를 뒤엎어야 하는 경우까지 생긴다.

 

이 방식이 아닌 좀 더 효율적으로 개발하기 위해서 이 방법론을 사용하게 된다.

 

그렇게 기존 형식보다 장 단점이 확실하게 들어난다.

 

개발 속도는 당연히 비교적 느리겠지만 코드의 버그를 찾아내면서 가는 것이 때문에 이런 문제를 바로 바로 해결해 가면서 한다.

 

또한 리펙토리에서 내가 사용해야 하는 변수 이름과 API의 중복과 문제를 바로 바로 알아낼 수 있어 코드를 보다 하나씩 

 

완벽하게 구현할 수 있는 장점이 있다.

 

또한 개발자들은 설계하는 과정도 개발에서 중요 요소이기 때문에 테스트 코드를 작성하는 것에 대해서 생각을 더 많이 요구하는 과정을 띈다.

 

하지만 제목을 " 왜 사용하는가? " 를 적은 것은 이런 방법이 있다는 것을 아는 것이지 이것을 무조건 해야된다는 아니다.

 

TDD는 정해진 케이스에서 코드를 발전해 나가는데 다른 필요한 요구사항 같은 것들과 테스트 케이스가 바뀌는 상황이 나왔을 때

 

유연하게 하는 것이 힘든 경우가 많다고 한다.

 

 

 

마무리

 

 

TDD 방법론은 시간이 많이 사용되는 단점이 조금 큰거 같긴하다.

 

하지만 그만큼 해결하는 능력은 좀 더 빠르게 성장하는 모습을 느끼는 것 같다.

 

Test를 하는 방법에도 여러가지가 있다고 한다.

 

근데 느끼기에는 그런 방법의 공통 되는 것은 어찌 되었든 어떤 조그만한 케이스를 완성하는데 만드는 코드를 작성하는 것이다.

 

이 방법을 사용하면서 개발 공부를 하고 있다.

 

처음이라 많이 낯설기도 하지만 적응을 해보려고 노력중이다.