[TDD워크샵] TDD(Test Driven Development)란 무엇인가

/* 11월 초, 첫 TDD 워크샵에 참여할 때부터 아, 배운내용 꼭꼭 정리해둬야지 했지만.....

업무와 테스트에 치여 바빴다는 핑계로 미루고 미루고 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

2019 설연휴 앞둔 이 때 2주동안 워크샵 휴강하고, 맡겨진 업무도 평소보다 루즈하니!!! 요 기회를 놓치지 않고 늦었지만 배운 내용들을 하나씩 정리해보고자 한다 */ 

TDD는 무엇?

처음 선배가 개발팀에 TDD 교육이 있으니까 한번 참여해볼래요?라고 물어봤을 때 TDD가 뭔지 전혀 몰라서 앞으로 2시간 동안 세미나실에서 지루하게 교육만 들어야하는거야?????? 했지만, 실제 TDD 워크샵에 처음 참석 배운 내용과 교육의 진행 방식은 내 예상을 완전히 뒤엎고 상당히 흥미로웠다.

TDD, Test Driven Development의 약자인 이 방법론은 테스트가 상당히 중요한 역할을 하는 소프트웨어 개발기법이다.

소프트웨어 개발(코딩)과 테스트 케이스 수행을 동시에 진행하는 방식.

무슨말이지..? 라고 한다면 도식을 보면서 이해해보자.

 [도식]

 

자 뭔가 개발할 프로젝트가 생겼고 대략적인 요구분석과 설계가 끝났다고 치자. 구현을 하는 단계에서 만약 TDD 개발방법을 도입한다면,

개발자는 크게 두가지 코드를 짜게 된다. 도식의 1번과 3번 프로세스에서 보이는 것처럼 하나는 테스트 코드이고, 다른 하나는 개발과제인 소프트웨어의 실제 구현 코드이다. 주로 테스트 코드와 구현 코드는 각각 다른 패키지로 묶어 구분하여 개발을 진행한다.

1. Write Test code: 테스트 코드를 작성한다. 개발자는 구현과제를 알고 있기 때문에 어떤 input을 주면 소프트웨어가 어떤 output을 뱉어내야하는지 대략적으로 짐작할 수 있고, 이를 토대로 테스트 코드를 작성한다. 예를 들어 1을 넣었을때 1이 나와야한다면? 테스트 코드 또한 아무 장치 없이 "1을 넣었을때 예상되는 값은 1이야"라는 문장만 작성한다.

2, Test Fails: 자 그렇다면 1의 테스트 코드를 구현코드에 대해 돌리면 결과는 어떻게 될까? 당연히 FAIL.

테스트 코드가 항상 구현코드보다 먼저 작성되므로 테스트코드를 돌리는 그 시점의 실제 구현코드는 테스트 하려는 input에 대해서 처리할 수 없는 상태이기 때문이다.

3. Write code: 이제부터 개발자가 해야할 일은 Fail이 뜬 1의 테스트 코드가 pass되도록 실제 구현 코드를 작성하는 것이다. 해당 input이  구현코드를 거쳐 expected output으로 return 되도록! 

4. Test Passes: 2에서 fail 됐던 그 input에 대한 implement(3)를 끝냈다면 실패한 그 테스트 코드를 다시한번 돌려 Test pass가 되는지 확인한다.

====================하나의 기능, 혹은 한 Class와 같이 단위를 나눠 위의 과정을 반복하면서, 들어올 수 있는 여러 입력값과 예외가 생길 수 있는 모든 값들에 대해 구현을 완료하면 해당 구현 코드(기능)는 테스트 코드에 의해 검증이 된다고 볼 수 있다. (이렇게 테스트 코드가 수행되면서 로직을 타고 검증된 구현 코드는 IDE의 Coverage 기능을 통해 확인할 수 있다.)

5. Refactor: 그렇다면 모든 기능에 대한 입력값이 기대값으로 처리되면 개발이 끝나냐? NOPE, TDD의 장점으로 꼽을 수 있는 Refactoring은 하나하나 입력값을 늘려가면서 코드를 구현하는 과정에서 중복되는 코드들을 찾아내 하나로 묶거나 더 효율적인 코드로 수정하는 사후 작업을 뜻한다. 예를 들어 1이라는 input을 처리하기 위한 코드와 2라는 input을 처리하는 코드가 하나의 변수만 다르고 모두 똑같다면 이 변수를 위로 뽑아내고 두 코드를 하나로 합칠 수 있다는 이야기다.

Refactoring을 하는 동안은 한 문장을 수정할 때마다 이전의 통과된 Test code를 수행하고 또 수행하며 해당 수정이 기존의 구현을 망치지 않는다는 사실을 확실히해야한다. 쉽게 말하면 '나 요만큼 고쳤는데(코드를 더 아름답게 만들었는데)도 원래 돌던 기능들 문제 없이 잘 돈다!!!!'를 입증하며 코드의 효율성을 높이는 것!

지금까지 TDD 개발기법의 기본 원리와 개념을 알아보았다. 애자일과 상당 부분 같은 맥락이라고 생각하는데,,,, 요부분은 나중에 더 깊게 생각해보면서 포스팅을 하기로 한다.

그렇다면 이를 도입했을때 얻어지는 장점은 뭘까? 

테스트를 통해 코드를 하나하나 검증하면서 개발이 진행되기 때문에 개발한 후 따로 테스트케이스를 작성하고.... 테스트하는데 시간을 쏟고.... 이 결과를 피드백삼아 다시 코드를 고치고.... 하는 과정이 무척 간소화될 수 있다. 기간은 줄어들지만 정확성은 UP되는 놀라운 개발기법!

또한 개발 당시 작성된 Test code를 통해 테스트 자동화가 가능해진다. 코드를 수정했다하더라도 개발당시에 작성한 Test code를 휘리릭 돌리고 이 결과를 보면, 소프트웨어에 결함이 생겼는지 아닌지 한눈에 확인할 수 있음!

다음 포스팅에서는 실제 TDD를 적용하며 진행한 TDD 워크샵의 한 과제에 대해 다뤄보고 좀더 자세히 TDD라는 놈을 파헤쳐보도록 하겠다.