TDD from starting from user stories - a top-down style 02

TDD from starting from user stories - a top-down style 02

 

Pros and Cons

Pros

 

acceptance test를 먼저하면 개발자는 코딩을 시작하기 전에 value에 대해 좀 더 생각할 수 있습니다.

여러분이 무엇을 테스트할지 정확하게 이해하지 않은 상태에서 acceptance test를 먼저 만드는 것은 정말 어렵습니다. writing test first라는 룰을 곧이 곧대로 적용하도록 하면 코딩을 하기 전에 business requirement 에 대해 개발자들이 좀 더 생각할 수 있도록 도와 줄 수 있습니다. 이 접근법은 개발자들이 business analyst들이나 고객을 직접 접촉해서 business를 먼저 이해하도록 독려할 수 있습니다. 그렇게 함으로서 요구 조건을 잘 못 이해하는 경우를 줄일 수 있고 현업(business people)과 개발팀 사이의 인식 차이도 줄일 수 있습니다.

 

Test automation은 프로젝트이 시작단계에서 부터 시작해야 합니다.

 

TDD 가 acceptance test부터 시작한다는 것은 모든 테스트에 대한 automation이 그 프로젝트 그 자체임을 암시합니다. 왜냐하면 자동적으로 프로젝트를 빌드하고 테스트들을 run 하는 작업 없이 빠른 feedback을 얻기는 불가능하기 때문이죠. CruiseControl같은 integration 툴들을 사용함으로서 이런 작업을 보다 쉽게 할 수 있습니다.

 

Clear and simple design, testable code

 

전에 얘기 했듯이 story와 acceptance criteria 의 business value 를 분명하게 이해해야 합니다. 그리고 나서 그것들을 가지고 테스트를 해야 합니다. 이제 남은 일은 이 테스트들이 pass 하도록 하기 위한 가장 간단한 코드를 만드는 겁니다. 만약 writing unit tests first 가 클래스의 각 public 인터페이스의 간단한 디자인을 얻는데 도움을 줄 수 있다면 writing functional tests first 는 business value를 implement 하기 위한 가장 간단한 디자인을 할 수 있도록 도움을 줍니다.

 

 

 

Tests as documents

 

TDD를 통해 얻을 수 있는 것 중 하나는 프로젝트의 documentation 역할을 할 수 있는 좋은 test들의 세트를 가질 수 있다는 겁니다. 수준 높은 functional test들을 가진다는 것은 모두에게 businiss requirement를 이해하는데 도움을 주고 이 functional test들을 단순히 수행함으로서 어플리케이션의 functionality 를 이해하는데 도움을 줄 수 있습니다.

technical people 들만 이해할 수 있는 우리의 test들을 non-technical people들도 이해할 수 있도록 translate 해 주는 툴들도 있습니다. (Testdox 같은). rspec 같은 testing framework들은 이런 종류의 일을 지원하는 built-in 기능이 있습니다. 그리고 rbhave와 jbehave 같은 다른 프레임워크들도 business natural language에 의해 그러한 기능들을 제공합니다. 이런 일들을 통해 우리의 test들은 business value를 좀 더 제대로 반영할 수 있고 이해하기도 쉽습니다.

Delay the implementing and design decision

 

테스트들을 보고 개발자들은 implementation을 수행하고 design을 결정하는 일을 진행할 수 있습니다.

 

nurture the good habits of programming

 

개발자들은 코딩이나 기술적인 문제에만 포커스를 맞추어서는 안 됩니다. 좋은 개발자는 정말 좋은 프로그램을 개발하기 위해 도움이 될 수 있는 모든 것을 고려하는 자세를 가지고 있어야 합니다.  Agile 소프트웨어 개발 방법론은 개발자들에게 좀 더 다방면으로 능력을 발휘하기를 요구합니다. 또한 질 좋은 코딩을 할 수 있는 능력을 갖추어야 하고 무엇을 할 것인지 에 대해 개발자는 확실히 파악하고 있어야 하고 해야 할 일이 그렇게 가치가 있지 않으면 해당 requirement에 의견을 제시할 수 있어야 합니다. 간단한 디자인으로 정말 유용한 코딩을 해야 하는 거죠. Story 를 근거로 한 TDD 는 이것을 가능하도록 도와 줍니다.

 

Testing team more effective

 

개발자에 의해 만들어지고 automated 된 functional test 들로 tester들은 좀 더 효율적으로 작업을 할 수 있습니다. Tester들은 대부분의 시간을 testing에 사용합니다. performance testing, exploratory testing 그리고 manual testing 등등이 있죠. 그들은 automated test들에 의해 진행될 수 없는 그런 테스트들에 그들의 에너지를 집중할 수 있습니다. 그들은 acceptance criteria 에 좀 더 시간을 투자할 수 있고 실제 작성한 테스트 코드가 아닌 그들의 testing idea 들을 제공할 수 있습니다.

실제 현장에서 일어나는 문제 중 하나는 어떤 tester들은 훌륭한 test code를 코딩하지 못한다는 겁니다. 이 문제는 사용하는 툴이 프로그래밍을 요할 경우 문제가 되죠. 그리고 프로젝트가 점점 커질 수록 test suite들도 점점 거대해 지게 되죠. 이런 문제는 개발자들인 좀 더 많은 functional test들을 작성하면 사라질 수 있습니다.

Agile planning에서는 한개의 story 에 얼마나 많은 작업이 필요한가에 대해 계산해야 합니다. 개발자들이 functional test를 먼저 작성하게 되면 좀 더 자신감을 가질 수 있고 해당 story 가 얼마나 시간이 걸릴지 좀 더 수월하고 정확하게 계산할 수 있습니다. 그렇게 함으로서 좀 더 쉽게 계획을 작성할 수 있게 되겠죠.

 

 

Cons

 

Sometimes it’s not easy

 

TDD 스타일에 대해 여러 장점들을 얘기 했는데요. 가끔 이러한 방식이 아주 어렵다는 것을 알고 있어야 합니다. 이런 방법을 여러번 경험해봤던 사람들에게는 아주 자연스럽고 쉽게 할 수 있는 일들도 그렇지 않은 사람들에게는 처음 받아들이기에 좀 어려울 수 있습니다. 대부분의 사람들에게 TDD 는 mind shift 를 요구 합니다. 대개 개발자들은 코딩을 먼저 하고 테스트하고 문제점들을 수정하는 순서대로 개발을 해 왔을 겁니다. 이들에게 드는 의문은 어떻게 코드 없이 테스트 부터 할 수 있을까 입니다. TDD를 적용하고 실제 그에 따르려면 이 의문점부터 먼저 해결 해야 합니다. 그래야 requirement들을 반영할 test를 작성할 수 있습니다. 처음에 이 작업은 쉽지 않습니다. 하지만 이는 처음 단계에 충분히 시간을 투자해서 익힐 가치가 있습니다. 우리 스스로 배우는 자세로 가치를 우선으로 두는 소프트웨어 개발을 생각해야 합니다. 유경험자와 같이 일을 할 수 있으면 이 방법론에 좀 더 빨리 잘 접근할 수 있겠죠.

 

Story 에서 TDD를 진행하는 방법은 몇가지 전제조건들이 충족 되어야 합니다.
첫째로 좋은 story 가 준비 되야 합니다. 좋은 story는 독립적이고 가치가 있고 예측할 수 있고 작고 테스트가 가능한 스토리여야 합니다.
좋은 스토리가 있으면 개발자들은 business value를 훨씬 쉽게 이해할 수 있고 좋은 question들을 제기할 수 있습니다.
그리고 작고 테스트가 가능해야 하는데요. 그래야 적정 시간 안에 writing test first 를 하면서 일을 끝낼 수 있습니다.

두번째로는 각 스토리에 대한 acceptance criteria 들이 분명해야 합니다. 그래야 개발자들이 그것을 근거로 쉽게 test들을 개발할 수 있습니다.
좋은 스토리는 성공적인 프로젝트의 corner stone 입니다.

 

Difficult in some areas like cpp, game, restricted by the availability of tool set

 

이 접근법에 대해 얘기 한 것 중 중요한 한가지는 좋은 functional testing tool을 갖는 겁니다. 실제 프로젝트에서 가끔 여러분의 어플리케이션에 맞는 좋은 functional testing tool을 찾는 것은 아주 어려울 수 있습니다. 여러분이 사용하는 프로그래밍 언어와 어플리케이션이 돌아갈 플랫폼 혹은 프레임워크에 따라 좀 더 어려워 질 수도 있습니다. 예를 들어 Windows desktop 어플리케이션을 위한 딱 맞는 툴을 찾기는 어렵습니다. QTP는 놓은 툴인데요 TDD에는 좀 무거운 감이 있습니다. 다른 예로는 게임이 있습니다. C나 Cpp를 사용하는 게임 프로젝트에는 TDD를 적용하기가 어렵습니다.

툴들도 진화합니다. 몇년전에는 웹 어플리케이션을 위한 툴을 찾기도 아주 어려웠습니다. 하지만 요즘은 웹 어플리케이션 functional testing을 위한 툴들은 아주 많습니다. 필요하게 되면 사람들은 좀 더 좋은 툴을 만들게 될 겁니다.

 

Build will get slow if not being careful because functional tests number increases

신경쓰지 않으면 Build 는 slow하게 될 겁니다. 왜냐하면 functional test들의 숫자가 증가하게 될 테니까요.

정의 하자면 functional test는 소프트웨어의 실제 functionality를 테스트 하는 겁니다. functional test에서는 대개 database들에 접근하고 네트워크를 통해서 데이터를 전달하고 파일을 읽고 쓰는 일 등등을 하게 됩니다. 일반적으로 발생하는 문제점 중 하나는 프로젝트가 점 점 커가게 되면 이런 모든 functional test들을 running 하는데 걸리는 시간이 훨씬 더 길어지게 된다는 겁니다. 이렇게 되면 functional test로부터 feedback을 빨리 받을 수 없게 되죠. 그리고 팀의 생산성도 떨어뜨립니다. 그러면 개발자들이 의도하지 않는 테스트들을 돌리고 의도하지 않는 functional test들을 작성하도록 만듭니다.

 

가끔 실제로 프로젝트를 진행하다가 그런 상황을 맞게 되는데요. 대부분 그 문제를 해결하기 위한 여러 해결방법들을 찾을 수 있습니다. 혹은 그냥 skip 할 수도 있죠.
예를 들어 개발 중에 functional test들을 작성하고 실행시킬 때 check in 하기 전에 모든 테스트들을 미리 run 해 볼 수 있습니다. 필요하면 테스트들을 좀 더 작은 group으로 나눠서 그 그룹들을 parallel 하게 돌릴 수도 있죠. 또한 우리의 테스트들을 reorganize할 수도 있고 stub과 mock을 사용해서 실제 외부 시스템에 접근하지 않고 테스트를 하도록 할 수도 있습니다.