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 가 얼마나 시간이 걸릴지 좀 더 수월하고 정확하게 계산할 수 있습니다. 그렇게 함으로서 좀 더 쉽게 계획을 작성할 수 있게 되겠죠.

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을 사용해서 실제 외부 시스템에 접근하지 않고 테스트를 하도록 할 수도 있습니다.

TDD 프로젝트에 참여하면서 정말 많은 것들을 배우고 있습니다.

새로운 프로젝트에 익숙해 지느라 블로그 포스팅을 오랫동안 못 하고 있는데요.

배우는 것들을 다 정리를 해 두지는 못하더라도 가능한대로 그때 그때 블로그에 정리를 해서 한번 배울때 더 확실히 이해하고 다음번에 같은 일을 할 때 좀 더 편하고 깊게 작업을 해서 점점 더 훌룡한 프로의 모습을 갖춰가고 싶네요.

또 그 글을 이렇게 공개된 블로그에 정리해 두면 다른 분들에게도 도움이 될 수 있을 것 같구요.

일단 개념 정리부터 하겠습니다.

써핑하다가 좋은 글을 발견해서 그 글 부터 정리해 둘 까 합니다.

http://exceedhl.thoughtworkers.org/Programming/2007/08/02/tdd-a-top-down-style.html

영어 되시는 분은 위 링크 가서 직접 보시면 좋을 거예요.

2007년도에 작성한 글이네요.

한번에 다 정리하지는 못하고 여러번에 나눠서 정리해야 될 것 같네요.

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

새로운 프로젝트에 투입되면서 모바일 쪽이랑은 완전히 멀어졌어요. T_T

지금은 은행쪽 프로젝트를 하고 있습니다.

한달동안 무지 헤맸는데 이제 조금씩 자리가 잡혀가고 있는거 같아요.

저는 Testing team 에 속해 있습니다.

현재 프로젝트에 TDD (Test Driven Development) 개념을 도입시키려고 하는데... 실제 일 시키는거 보면 그것 보다는 일단 JUnit 으로 TestCase 들 만드는게 주 일 입니다.

한달동안 일하면서 들었던 여러 용어들을 일단 적어 놓으려구요.

아마 이번 프로젝트 하는 기간에는 이 용어들과 관련된 기술에 대한 글들을 위주로 블로깅을 할 것 같네요.

- 프레임워크는 기존 Struts 프레임워크를 사용하는 애플리케이션들이 있고 새로 만드는 애플리케이션들은 Spring을 사용할 것임

- LLD (Low Level Degien) 문서를 근거로 JUnit 으로 TestCase를 만듬

  그런데 지금까지는 TDD 개념을 프로젝트에 적용하지 않아서 이 부분이 미진함.

- JUnit, JWebUnit, Soup UI 등의 테스팅 툴들을 사용할 것임

- 애플리케이션 단에서 Web Service 와 연계된 메소드들을 테스트 하기 위해서는 Mockito, inject 를 사용함

- Web Service 테스트는 Soup UI 로 함

- JWebUnit 은 UI 단 테스트의 Automation 을 위해 사용함

- 그 외 Functional Testing, Acceptance Testing 등을 진행 함

- Mobile을 위한 어플리케이션도 있는데 이 부분은 Struts를 사용함

- IDE 는 JBoss Studio 4.0 을 사용함 (Eclips 와 거의 같음)

- Maven 으로 Dependancy 관리 함

- MKS Integrity 에서 소스파일 관리를 함

- JDK 1.6 을 사용함

- Oracle 11G를 사용함

일단 기억나는 것들은 이런 것들 입니다.

앞으로 이 프로젝트가 끝날 때까지 이와 관련된 기술들을 깊이 공부할 생각입니다.

프로젝트가 은행 온라인 뱅킹 관련 프로젝트인데요.

이곳 온라인 뱅킹은 한국의 은행 온라인 뱅킹이랑 조금 다른점이 있는거 같아요.

새로운 분야를 공부할 좋은 기회입니다.

프로젝트 기간이 6개월이니까 최소한 그 기간동안은 이쪽에서 사용되는 기술이나 개념을 익히는게 우선이겠네요.

물론 관심이 있는 모바일 쪽도 계속 공부는 할거지만요.

여기 캘리포니아 쪽에서 모바일 인력 필요하신 분들은 연락 주세요....

뭐든지 배우려면 실무를 하면서 배우는것이 더 효율적이잖아요.

다음 프로젝트는 모바일쪽을 하고 싶네요....

여기도 모바일쪽과 연관된 분야가 있으니 그쪽 일을 좀 더 많이 맡아야겠어요.

지난달에는 거의 글을 못 올렸는데요.

아마 당분간 여기 일이 익숙해 질 때까지는 글 올리는 일이 힘들 것 같습니다.

일이 익숙해 지면 계속 공부하면서 글 올리겠습니다.