[개발 방법] 테스트 주도 개발(Test-Driven Development)에 대해서

오늘은 테스트 주도 개발(Test-Driven Development) 줄여서 TDD에 대해서 알아보고 장점과 단점은 무엇인지 공부해 본다.

 

 

테스트 주도 개발(Test-Driven Development)에 대해서

테스트 주도 개발 줄여서 TDD는 테스트 위주로 고려해서 개발을 하는 개발 방법론 중에 하나이다. 반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다. 기존의 일반적인 방법론과는 다소 다르게 테스트를 매우 중요시한다는 것이 핵심이다.

 

아래는 켄트 벡의 테스트 주도 개발이라는 책에서 설명하고 있는 내용이다. 테스트 주도 개발의 바이블과도 같은 책이라고 할 수 있다.

 

테스트 주도 개발은 학계와 업계에서 많은 주목을 받아온 프로그래밍 방법으로, 여러 연구 논문과 실례를 통해 개발자의 생산성과 역량을 증폭시켜 준다는 사실이 받아들여지고 있다. 테스트 주도 개발은 테스트가 개발을 주도하는 방법이다. 테스트가 개발을 주도한다는 것은 테스트가 코딩의 방향을 이끌어 간다는 말이다. 테스트를 실패하는 코드가 없으면 코딩을 하지 않고, 코드상에 중복이 있으면 제거한다는 간단한 규칙을 지켜나가면 자연스레 아름다운 코드가 천변만화 펼쳐진다. 덤으로 회귀 테스트도 생기고, 개발 과정 자체가 즐거워지는 보너스도 있다. 이 책의 저자 켄트 벡은 테스트 주도 개발을 퍼뜨린 장본인이며 객체 지향 프로그래밍의 선구자 중 한 사람이다. 이 책을 통해 독자는 켄트 벡의 옆에 앉아 함께 프로그래밍을 하는 값진 경험을 할 수 있을 것이다.

 

http://www.yes24.com/Product/Goods/12246033

테스트 주도 개발 - YES24

 

일반적인 개발 프로세스

모든 개발이 이렇게 이루어지지는 않겠지만 일반적으로 개발을 한다고 하면 대체로 아래와 같은 프로세스로 진행된다.

• 필요한 기능이나 프로그램을 요구사항에 맞게 설계를 한다.
• 설계를 기반으로 각 기능의 코드를 구현한다.
• 설계와 코드 구현을 반복한다.
• 테스트를 한다. 이때 대부분 통합 테스트다 E2E 테스트 수준으로 할 수밖에 없다.
• 실패하면 다시 설계하거나 코드를 수정하며 반복한다.

참고 : https://teamdable.github.io/techblog/TDD-and-wallaby

 

일반적인 개발 프로세스

 

 

 

테스트 주도 개발 프로세스

일반적인 개발 과정과는 조금 다르게 설계 단계에서 요구사항을 분석해서 실패하는 테스트부터 작성하는 것으로 개발을 시작한다고 볼 수 있다.

• RED: 실패하는 테스트 코드를 작성한다. 컴파일조차 안될 수도 있다.
• GREEN: 테스트에 통과할 만한 작은 코드 작성해서 통과시킨다. 희열을 느낀다.
• REFACTOR: 코드를 조금 더 효율적으로 리팩터링 한다. 
• 이 과정들을 반복하면서 개발한다.

테스트 주도 개발 프로세스

 

 

테스트 주도 개발의 장점

대체로 장점으로 나와 있는 것을 바탕으로 내가 실제로 해보고 생각했을 때 장점을 정리하면 다음과 같다.

• 사용자의 관점에서 생각하면서 객관적인 개발이 가능하다. 즉 인터페이스 설계가 좀 더 잘 될 수 있다.
• 테스트를 별도로 만들 필요 없이 개발이 끝나면 테스트가 완성되어 있다.
• 이 테스트들이 바로 문서가 될 수 있다. 
• 디버깅하는데 소요되는 시간이 감소한다.
• 내가 만든 코드에 자신감이 생긴다.
• 의미 있는 코드리뷰가 가능하다.

직접적인 장점이 굉장히 많은 개발 방법이다. 이를 통해 구성원의 역량향상과 소프트웨어의 품질 및 유지보수성의 향상이 덤으로 따라올 것이다. 하지만 잘 적용하고 유지되는 이상적인 상황일 때 가능한 일이다. 그만큼 노력이 많이 필요하고 단점도 있다.

 

 

테스트 주도 개발의 단점

• 처음 하면 시간이 많이 걸린다. 노하우가 많이 필요하다.
• 레거시 코드가 많으면 테스트 자체를 만드는데 Mock이 너무 많이 필요할 수 있다. 너무 비효율적이다.
• 비슷하게 하드웨어의 비중이 높은 임베디드나 펌웨어의 경우 작은 단위 테스트가 별로 효과가 없을 수 있다.
• 자칫하면 의미 없거나 너무 견고한 테스트로 인해 조금만 수정해도 실패하는 깨지기 쉬운 테스트가 될 수 있다.
• 여러 개발자가 지속적으로 유지하기가 쉽지 않다.

이러한 단점이 있지만 그럼에도 불구하고 한번 시도해 보고 느껴볼 만한 방법론인 것 같다.

 

결론

개인적으로는 테스트 주도 개발의 목적과 추구하는 방향에는 전적으로 동의한다. 또한 이런 관점을 갖고 개발했을 때 분명히 개발 아웃풋과 역량향상에 도움이 되는 것을 몸소 체험했고 계속 체험하는 중이다. 하지만 그만큼 많은 노력과 에너지가 드는 것임에는 분명하다. TDD를 신경 쓰면서 개발하면 길게 보았을 때 생산성과 역량향상 그로 인한 좋은 문화와 소프트웨어의 좋은 품질을 얻을 수 있는 것은 명백하다. 하지만 맹목적으로 강요한다거나 오/남용되었을 때 비효율적일 수 있고 개발 과정이 너무 힘들어질 수도 있다. 사람의 성향과 조직의 상황에 맞게 적절하게 적용하는 것이 가장 좋을 것이고 이는 시행착오가 필요할 것이다.

 

이러한 토론이 전문가들 사이에서도 진행되었다. TDD는 죽었다는 포스팅에서 시작되어 저명한 개발자들 간에 토론을 주고받은 내용을 정리해 놓은 블로그이다. 개인적으로 매우 흥미롭게 봤고 전문가들도 생각하는 게 비슷하구나라는 것을 느꼈다. 한번 보는 것을 추천한다.

https://jinson.tistory.com/271