작성의도

이 글은 전남대학교 개발동아리 Econovation 내에서 내가 하는 4번째 프로젝트입니다.

사내 Tech Blog 를 만들기 위해 시작한 이 프로젝트에서 내가 백엔드 개발 공부를 하면서 적용시켜보고 싶은 기술 스택이나 방법론들을 적용시켜볼 계획입니다.

특히 이번 프로젝트에서는 스타트업에서 많이들 사용하는 TDD를 적용시켜 설계를 해볼 겁니다.

TDD ( Test driven Development )

• TDD란 Test Driven Development 즉, '테스트 주도 개발'이라고 한다. 반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.
  짧은 개발 주기의 반복에 의존하는 개발 프로세스이며 애자일 방법론 중 하나인 eXtream Programming(XP)의 'Test-First' 개념에 기반을 둔 단순한 설계를 중요시한다.

자세한 설명을 한문장으로 하기는 어려우니 먼저 기본 개발 방식과 차이점을 살펴보면서 이해해보도록 하자.

일반 개발 방식

1. 일반 개발 방식

• 보통의 개발 방식은 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포의 형태의 개발 주기를 갖지만 이는 큰 문제점을 내포하고 있다.

1. 소비자의 요구사항이 처음부터 명확하지 않을 수 있다.

2. 따라서 처음부터 완벽한 설계는 어렵다.

3. 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있다.

4. 테스트 위주로 개발하다 보니 개발의 속도나 생산성에 큰 문제가 생길수 있다.

결국 이런 설계는 유지보수가 어려워지게 만드는 큰 요인이다. 또한 작은 버그가 하나 발생했을 당시에 차후에 버그 추적하기도 어렵고 모든 기능을 다시 테스트해봐야 하는 문제점도 있다.

2. 테스트 주도 개발 방식

• 일반 개발 방식과는 다르게 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 점이다.

• 디자인(설계) 단계에서 프로그래밍 목적을 명세서를 작성하거나 다양한 방법으로 사전에 논의를 마쳐야 하고, 무엇을(테스트 케이스 작성) 테스트해야 할지 미리 정의해야한다.

• 이런 단계를 거치면서 소스 코드는 유지보수 하기 쉬워지고 간결해진다는 장점이 있다.

• 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선된다.

• 위의 그림은 TDD의 개발주기를 표현한 것이다.

• 중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 하는 것이다. 이를 통해, 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있다.

<Red>단계에서는 실패하는 테스트 코드를 먼저 작성한다.
<Green>단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
<Yellow>단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.

조심할 점

1. 실패 테스트 코드를 작성할때 까지 실제 코드를 작성하지 않는다.
2. 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 한다.

TDD 개발 방식의 장단점

TDD 개발의 장점

• 보다 튼튼한 객체지향적인 코드 개발
  - TDD는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 보장하여 차후에 제거하거나 추가해도 전체 Structure에 큰 영향을 미치지 않는다.

• 재설계 시간의 단축
  - 지금 무엇을 개발해야 하는지 정의하고 개발을 시작한다. 그리고 테스트 시나리오를 작성하면서 예외사항을 생각해 볼 수 있다.
  쉽게 말해 딴길로 새지 않는다.

• 디버깅 시간의 단축
  - 유닛 테스트를 하면서 버그가 어디서 나오는지 (DB, Service, Repository 등등) 파악하기 쉽다.

• 테스트 문서의 대체 가능
  - 어떤 요소들이 테스트 되었는지 정의서를 만드는데 TDD를 하면서 테스팅을 자동화 시킴과 동시에 정확한 테스트 근거를 산출할 수 있다.

이런 장점들이 있다.
그러면 이걸 왜 많은 사람들이 사용하지 않을까??

으아 귀찮아...

TDD개발의 단점

• 생산성의 저하
  - TDD개발 방식은 일반 방식보다 10~30% 정도로 늘어난다.
  SI 시장에서는 소프트 품질보다는 납기일이 중요하기 떄문에 사용하지 않는다.

  Money is way more important than Quality
  

• 평소 내가 개발하던 방식을 뒤집어야 한다.

• TDD의 편견
  - 툴단위 테스트 프레임워크 (JUnit 같은거)를 꼭 사용해야 한다고 생각한다.

  • 똑같은 테스트를 Copy&Paste, Test를 할 수 있다.

Back Door 접근 법 : 테스트할 때 파라미터를 적용하여 본인이 원하는 시스템의 시작점으로 가게 하는 것.

즉, 중복적으로 하는 노력들을 자동화하도록 업그레이드하면 발전할 수 있다.

먼저 TDD는 XP(Extreme Programming) 이 아닙니다. 전혀 Extreme 한 방법이 아닙니다.

reference : https://wooaoe.tistory.com/33