-
http://wikidocs.net/mybook/read/page?pageid=3019 책 요약
http://xper.org/LineReaderTdd/ LineReader TDD 동영상
http://www.xper.org/wiki/xp/TestDrivenDevelopment?action=show&redirect=TDD
http://www.agiledata.org/essays/tdd.html#Summary
셋째날
테스트 주도 개발(TDD)
- "살리고" 철학(살리고 철학은 TDD의 철학적 근간으로, 작동하는 소프트웨어에서 작동하는 소프트웨어로 상태전이하는 것이 가장 효율적이라는 철학입니다)
- 살리고 철학 실습
- 테스팅의 필요성
- Computer Aided Testing
- 자동화된 단위 테스팅
- 자동화된 단위 테스팅 실습
- TDD 기초
- TDD 기초 실습
- TDD 응용 (Mocking & Legacy code)
- TDD 응용 실습
- TDD anti-patterns
Exploratory Testing(탐험적 테스팅)
- Exploratory Testing 실습(코드 레벨)
[질문] Agile의 TDD 글쓴이 : 최피디 날짜 : 08-08-16 13:49 조회 : 444 본인은 온라인게임 서버를 개발하는 과정에서 unit test를 활용하여 테스팅의 효용성을 체험적으로 알게 된 후 Testing 분야에 관심을 갖고 공부를 시작하고 있는 초심자입니다.
최근에 Ron Patton의 Software Testing 2nd ed을 읽으면서, 제가 해왔던 테스트 방식 TDD(Test Driven Development)에 대한 우려가 느껴져서 제가 느낀 점이 과연 그러한지 검증해보고 싶어 문의드리오니 부디 너그럽게 초보자를 지도해주시기 부탁드립니다.
저는 TDD를 책을 통해서 배우게 되었습니다. 켄트 백의 테스트 주도 개발이 그 책인데요. 이 책을 보신 분들은 잘 아시겠지만, 이 책은 소프트웨어을 만들어가는데 지극히 경험적인 접근을 하고 있습니다. 다시말하자면, 설계나 계획에 의한 테스트케이스 도출이 아니라, 현재 상황의 가장 중요한 개발 이슈들이 무엇인가를 목록으로 만들어서 하나씩 삭제시켜가는 방식이었습니다.
테스팅에 대해서 너무 설계과정 없이 무작정, 감으로만 테스트케이스를 만들어 가게 되는데요. 이렇게 유닛테스트 케이스를 만들어가는 것에 문제점은 없는지, 전통적인 테스팅 그룹에서는 TDD에 대해서 어떤 식으로 평가하는 지 궁금합니다.
감사드립니다.
박정훈2 08-08-18 10:52 
안녕하세요. 박정훈이라고 합니다.
오며가며 한 번 쯤 P-Camp 같은데서 뵈었을 것 같네요.
STEN의 이현주 강사님께서 소개해 주신 사이트입니다. James Bach(http://satisfice.com), 제임스님의 방법이라면 '전통적' 접근 방법과 최근의 Agile 접근 방법을 함께 생각해 보고 회고해 볼 수 있다고 생각됩니다. 참고하시기 바랍니다. :)
(게으르다보니 최근에 알게된 데다가 내용이 심오해서 모두 숙지하지는 못했습니다. 능력 부족으로 자세한 내용 설명이 불가하네요.)
하나 제 의견을 말씀드리자면, 전 세계 어느 Test Group도 별로 그닥 '전통적'이지는 않습니다. 늘 '개선' 해야 하기 때문입니다. (저도 게임 업계에서 tester로 있었지만,) 게임 업계분들이 Test와 Agile을 다르게 보려고 하시는 것 같은데, 전 'organization's improvement' 측면에서 같은 방향으로 가고 있다고 생각합니다. ^^
즐거운 하루 보내세요.최피디 08-08-18 22:12 박정훈2님
동명이인(同名異人)이 있으신가 보군요. 정훈님께서 소개해주신 사이트는 막 들어가 봤습니다. satisfice는 1인기업 회사인 거 같아 놀랍네요. '한 명의 테스트 전문가로 만들어진 회사라니...' 제임스의 여러 방법 중에 어떤 것이 Agile접근 방법과 비교될 수 있을 지 살펴봐야겠습니다.
Organization's improvement(조직의 성장?) 란 용어가 테스팅에서 쓰는 의미의 것인지 궁금합니다. 구글링을 해도 딱 찾아지지 않아서 여쭙습니다.
이렇게 생각의 단초(端初)들을 제시해주셔서 참 감사드립니다.
오프라인에서 한 번 뵐 수 있다면 더 좋겠네요. ^^임준섭 08-08-20 12:52 James bach는 exploratory testing의 창시자입니다.
9월이었나..10월이는지 지금 잠시 헷갈리는데..
국내로 어렵게 초빙하여 교육을 진행할 것입니다.
정부지원을 받으려고 시도중인 것으로 알고 있고, 조만간 공지를 통해 소개해 드릴 것입니다. ^^
Organization's improvement는 테스팅 업계에서 공식적으로 쓰이는 용어는 아니고, 제 생각엔 아마도 조직의 개발 프로세스 개선 정도로 언급하신 듯 싶습니다.최피디 08-08-21 11:28 임준섭님,
고맙습니다. exploratory testing이란 것인 피드백을 강조하는 귀납적 방식의 테스팅이로군요. 이점이 Agile과 연계되는 부분이 있는 것 같다는 심증(心證)만 있는 상태입니다. 혹시 테스트과 agile 이 둘을 함께 다루고 있는 자료는 없을까요?
감사합니다.박정훈2 08-08-21 20:53 임 팀장님께서 잘 설명해 주셨군요. 역시 최고십니다. :)
최 피디님,
제 개인적인 경험입니다만... 게임 업계에 도입된 애자일 방식이 못 마땅합니다.
언젠가 직접 뵐 기회가 있으면 조금은 더 자세히 설명 드리겠습니다. :)최피디 08-08-22 10:41 박정훈님,
저는 게임 업계에 도입된 애자일 방식이 어떤 것인지 아직 많이 이해가 필요합니다.
그런 기회가 있다면 개인적으로 영광이겠습니다. :)최피디 08-08-25 11:14 Agile 프로세스에서 QA는 필요없다는 주장에 대해서 반박하고 있는 글입니다.
http://www.extremeplanner.com/blog/2006/02/is-qa-redundant-for-agile-software.html박정훈2 08-08-25 13:33 좋은 글 감사드립니다.
좋은 글 소개해 주셔서 보너스로 아래는 Kelly Water님의 블로그를 번역한 글을 올려드립니다.
제가 번역했습니다. ^^ 기술서/기술 관련 번역이 점점 재밋어 지네요.
--------------------------------------------------------------------------
* 원문 주소: http://www.agile-software-development.com/2007/03/why-agile-testers-should-be-in-at-start.html
저의 경험상, 어떤 이들은 애자일 개발방법론을 적용할 때 개발팀을 제외한 다른 주요 직무(예를 들어, 사업 고객이나 테스터들)를 애자일 팀에서 빼두거나 꿔다논 보릿자루처럼 두고 개발팀안에서만 애자일 원리들(agile principles)을 수행하곤 합니다.
제가 블로그 초기에 작성한 것 중에, 애자일로 개발을 진행하는 중에는 많은 이유로 인해 능동적인 사용자의 참여가 필수이다(active user involvement is imperative)라는 글을 포스팅한 적이 있습니다. 각 기능이 실제로 완료되었는지 보증하기 위해 필요한 모든 직무는 애자일 팀에 각기 그 나름대로 중요한 역할을 담당합니다. 여기서 "완료(complete)되다"라는 개념은 각 반복(iteration)이나 스프린트(Sprint)의 끝을 말하는 것입니다.
개발 착수 시기부터 테스터들을 포함하는 것, 특히 계획 단계에서 테스터들을 참가하도록 하는 것은 무척 좋은 생각입니다. 왜냐하면:
* 테스터들은 요구사항들을 이해하기 쉽게 만든다거나, 대안이 될 수 있는 시나리오를 식별해 내는 일에 유별나게 훌륭한 경향이 있습니다. 요구 사항을 설명하고 단계별로 계획하는 방식으로 생각하는 것은 업무에 할당된 품질 수준의 산정치를 향상시키게 되며, 그러므로 고려된 일정 내에 성공적으로 배포할 수 있는 기회 역시 증가하게 됩니다.
* 더 중요한 것은 테스트 선행 접근 방법이 알려졌을 때, 개발자들은 이런 접근 방법론을 이용하여 그들이 작성하는 코드가 문제 없이 통과되기만을 바라는 경향이 있습니다! (제가 일전에 작성한 테스트 주도 개발(test driven development)을 참조해주세요.)
* 요구 사항 설명과 직접적인 계획에 참가한 테스터들은 무엇이 필요하고 어떻게 수행할 것인가에 대해 더 잘 이해를 할 수 있으며, 그들이 좀 더 나은 테스트 업무를 수행 가능하도록 만들어 줍니다. 애자일을 이용하여 개발하는 프로젝트들에서는 장황하고 긴 명세서가 존재하지 않는 상태에서(In the absence of a lengthy specification) 테스터들이 그들의 업무를 효율적으로 수행할 수 있도록 하는 필수 요소입니다.
* 그리고 테스팅은 각 스프린트에서 완료된 모든 기능들에 대해서 반드시 수행되어야 하는데, 여기에서 기능이 완료되었다함은 진짜로 "100% 완료된!" 것을 의미합니다. 예를 들어, Production Ready(역자주 3 참조)
* 참고: 10 Key Principles of Agile Development
http://terra.springnote.com/pages/1581586
http://jangxyz.springnote.com/pages/1416448?print=1
http://me2day.net/tag/tdd
http://cespc1.kumoh.ac.kr/~juyoon/lecture/java/note08/Java08_XP.pdf
Test-Driven Development
eXtreme Programming
테스트 주도 개발
What is TDD?
목표 소프트웨어에 대한 테스트 프로그램을 먼저 (또
는 동시에) 개발
반복적 과정 (iterative process)
Why TDD?
빠르게 오류 없는 소프트웨어 개발
•
개발된부분에대한짧은테스트로빠른피드백가능 Why not TDD?
GUI, Relational DB
복잡한 I/O 로 인해 분리된 단위 테스트가 어려운 경우
eXtreme Programming
개발 과정
다음 과정을 반복한다.
Add a test
•
개발의시작은테스트를만드는것부터
!
•
요구사항에대한명확한이해가필요
Use Case, Scenario
Run all tests and see the new one fail
•
새로운테스트는새로운코드를요구한다
! sanity check
Write some code
•
테스트를만족하는코드작성 •
테스트에없는새로운기능을추가하면안된다
!
Run the automated tests and see them succeed
•
새로운코드가테스트를통과하는지체크 Refactor code
•
중복또는비효율적인부분을제거하고테스트통과
eXtreme Programming
테스트 프로그램 작성
Black-box test
개방된 인터페이스만 사용하여 기능 테스트
내부 변수를 바꾸거나 private 변수를 테스트하지 않
는다.
Software modularity 유지
별도의 프로젝트(또는 모듈)로 작성
최종 코드에 가해질 수 있는 부수 효과 제거
테스트 종류
Unit test
Integration test
Acceptance test
eXtreme Programming
테스트 프로그램 작성
권장 사항
test로 시작하는 메소드 사용
테스트 코드 내용
•
테스트에필요한모든조건과상황을준비설정 •
테스트대상메소드호출 •
테스트대상메소드가원하는대로동작함을검증 •
실행이끝나고다른코드에영향이없게정리작업
http://en.wikipedia.org/wiki/Test-driven_development
역자나 저자나 조금 거만한 거 아냐?
라는 것이었다. 그래서 책을 읽고 싶지는 않았으나, 돈도 아깝고 이왕 시작했으니 봐야했다. 하지만, 내 그런 기분도 잠시였다. Kent Beck이라는 저자는 글을 읽는 내내 웃을 수 있게 해주었다.
모든 작업을 간단 간단히 쪼개서 하는 것은 이미 많은 개발자들이 해왔던 바일 것이다. 조금 개발하고 디버그 하고, 조금 개발하고 디버그 하고.. 머리 속에 알게 모르게 초록 막대, 빨강 막대를 생각하고 있었을 것이다.
다만, 그것을 드러내서 많은 사람이 인식하게 했다는 점이 이 TDD의가 아닐까?라는 생각을 해본다. 그리고 여기서 말하는 사고의 크기들이 너무 큼직 큼직했다는 점이 현재까지의 문제점이었다.
이전부터 TDD의 이점에 대한 많은 이야기를 들어왔으나 내 스스로의 기술이 미비한지라 기술을 익히느라 미쳐 책을 읽지 못했으나 시간이 나서 잠깐, 아니 어쩌면 길게 읽어보았다. JUnit을 처음으로 써봤을 때 매우 편리하다고 생각했었는데 이 책을 읽음으로써 그 전부터 암묵적으로 행하고 있던, 테스트-빨강-초록의 그 단계들을 명시적으로 드러내서 하게 되는 계기가 되었다.
물론 저자처럼 눈에 불을 켜고 심각할 정도로 테스트를 먼저 할 것은 아닐거라는 것을 스스로 잘 알고 있긴 하지만, 상당히 즐거운 논조와 즐거운 프로그래밍을 하는 저자의 모습처럼, 나도 저자처럼 즐겁게 생활하는 모습을 떠올리며 이것저것 많은 생각을 하게 되었다.
아키텍쳐(static)를 만드는 다양한 프레임워크들과 Growing이라는 개념을 적용한 TDD(dynamic)의 개념들에 대해 생각해 보다 보니, 이 책의 가치가 더욱 높아진다. 게다가 프로그램을 키워가는 식으로 애정을 가지고 보는 것은 이 얼마나 좋은 것인가?
오랜만에 보석같은 책을 읽게 되어서 기분이 좋았다.
그리고, 역자분께서는 꼼꼼하게 뒤에 혹여나 이해를 못할까봐 부록으로 직접 잘 안되는 부분에 대한 이야기까지 적어 두셨다.
매우 감사할 노릇이다. 처음부분에서 좀 겁을 먹었지만, 어쨌든 우리와 우리의 프로그램을 발전시키는 건 그러한 [[[ 두 려 움 ]]]이 아닐런지..
[장점]
1. TDD가 무엇인지 직접 보여준다.
2. 스트레스에서 벗어날 수 있는 방법을 보여준다.
3. 웃기다.
[단점]
1. 도입부가 거창하고 거만해서 겁먹게 한다.
2. 중복되는 내용이 있다.
3. 저자가 생각하는 낙관적인 개념에서 설명하는 경우가 있다.
켄트 벡 아저씨의 유명한 "테스트 주도 개발"을 이제서야 보게 되었다.
켄트 벡 아저씨의 재치있는 입담이 일품이었다.
이 책은 나에게 매우 큰 충격으로 다가왔다. "테스트 주도 개발"이란 말 자체는 예전부터 들어왔고 또 실용주의 프로그래머에서 본 것 처럼 단위 테스트의 중요성 및 효용성에 대해서는 (문자로는) 익히 알고 있었던지라 별로 새로운 내용은 없겠거니 라는 생각을 가지고 책을 보았다. 그러나 읽어가면 읽어갈수록, 내 머리속에 전구가 켜지기 시작했다. "테스트 주도 개발"이란 말은 단지 그대로 풀어서 "테스트를 중심으로 하는 개발" 이라는 것으로는 부족함이 있다. 개발 방법 자체를 논하고 있는 것이었다.
테스트를 중심으로 개발하는 것은 물론이요, 단지 요구사항을 테스트로 표현해서 거꾸로 문제에 접근하는 것 뿐만이 아니라 (저자의 말을 빌어) 테스트를 통해서 정원을 가꾸듯이 미시적인 관점(단위 테스트)에서 코드를 키워가는 것, 설계해 나가는 것을 의미한다.
이것의 절묘함은 무엇이냐면, 일단 테스트 목록을 요구사항에 맞게 정확히 뽑아내고(이것이 제일 중요한 것 같다.) 그것을 그대로 테스트 코드로 표현하고, 구현하며, 테스트가 통과하면 그때부턴 테스트 코드 작성을 중단하고 실제 모델 코드를 리팩토링하며 정리하는 방식이다. 이런 과정에서 요구사항을 파악할때는 아무것도 생각 안하고 지금 하려고 하는 것이 무엇인지만 정확히 파악하여 테스팅 코드를 작성하고, 리팩토링 할때는 아무것도 생각 안하고 리팩토링만 하면 된다. 단지 리팩토링한 결과가 테스팅을 통과하기만 하면된다.
여기서도 묻어나오는 절묘함. 이런 테스트 주도 개발을 실행하기 위해서는 각각의 단위 테스트 모델 코드들이 결합이 될래야 될 수가 없다. 각 단위마다 직교성이 유지되고 문제는 그 곳에서 더 이상 퍼져나가지 않으며 각각의 단위에 대해 집중할 수 있다. 나오는 결과물은 깔끔 그 자체.
또한, 테스트를 한다 와 테스트를 가지고 있다 를 이 책에서는 구분을 하는데, 테스트 주도 개발을 실행하면서 쌓인 신뢰할 수 있는 수천가지 테스트들은 곧바로 실행 가능하며, 이 테스트들의 성공 및 실패 여부가 실제 어플리케이션의 오류와 대응되기 때문에 나중에 어떤 변경사항이 있을 경우에도 변경을 가한 후에 자동화된 테스트들을 돌려보면 곧바로 결과를 알아볼 수 있다는 점 또한 획기적이다.
실천해 보아야겠다는 생각이 강하게 드는 중인데, 역시 이 TDD도 수련이 필요한지라 익숙해지기란 쉽지 않은 것 같다. 그리고 무엇보다도
게임 개발에 있어서 과연 이 TDD가 얼마나 효용성을 거둘 수 있을지 의문이 든다.
일반 어플리케이션이라면 모르겠는데, 게임 어플리케이션 같은 경우는 실시간으로 돌아가는 데다가 네트웍, 그래픽, 사운드, 인터페이스 등등 온갖 것들이 맞물려 돌아가는 복잡한 시스템이다.
저자가 말하는 것은 아무리 복잡하고 큰 시스템이라 할 지라도 TDD가 가능하다는 입장이며, 이는 시간이 지나면서 어느정도 검증이 된 모양인데 일단 게임 개발용 툴과 내부적으로 쓰이는 모듈들에 대해서는 TDD로 개발이 가능할 것 같다.
시작할 수 있는 조그만 것부터 적용시켜 보기로 했다. 전혀 손해볼 것이 없다는 생각이 든다.
나는 집중의 힘을 잘 알고 있다.
TDD는 Agile development 방법론의 가장 중요한 요소 중의 하나이다. Coding을 많이 하여 본 경우 test를 자동적으로 하는 것의 잇점을 매우 잘 느끼고 있다. 또, code가 이미 작성되고, 동작하는 상태에서 test code를 작성하는 것이 매우 힘들고 현실적으로 어렵다는 것도 알고 있다. 이를 해결하는 극단적인 방법이 code를 작성하기 전에 code를 test하는 code를 작성하는 것이다.
TDD는 code를 테스트하기 위한 unit test를 code를 작성하기 전에 작성하는 것을 말한다. 새로운 객체를 작성하기 전에 그 객체를 검증하기 위한 test case를 작성한다. Test case의 작성이 끝나면 해당 object에 대한 예상 입력, 출력, boundary case, error condition등에 대한 정의가 완료되고 이런 작업을 검증할 수 있는 test case를 가지게 된다. 테스터나 사용자에 의하여 발견되는 많은 결함은 예상하지 않은 input이나 error 조건과 관계가 있으며, 이미 객체가 제대로 동작하지 않을 모든 경우를 고려하였기 때문에 이런 결함을 보완하는 것이 가능하다.
TDD는 프로그래머가 요구사항을 더 잘 이해할 수 있도록 도와준다. Code가 구현하려는 기능에 대한 이해가 부족한 상태에서 coding을 시작하는 경우가 많이 있다. 요구사항을 문서화하는 것보다 coding을 하는 것이 재미있으므로 이런 일이 자주 발생하며, 문서화된 요구사항이 존재하지 않는 경우도 존재한다. 약간의 대화나 흐릿하게 범위를 이해한 상태에서 software의 개발이 시작될 경우 coding을 당장 시작하는 것이 더 재미있다. 이 경우 unit test를 작성하기 위하여 시간을 할애하면 programmer의 마음에 존재하는 요구사항을 확실히 할 수 있으며, 어떤 경우에는 빠진 정보가 무었인지 정확히 아는데 도움을 준다.
TDD는 여러가지 잇점이 있다. 가장 명백한 것은 unit test가 언제나 작성되는 것이다. Code release가 다급한 경우 작동하는 것처럼 보이는 상태의 code를 release하려는 경향이 있다. Unit test가 가장 마지막 단계에서 이루어질 경우 일정에 쫓길 경우 unit testing을 생략하는 경우도 있다. Unit test없이는 code에 더 많은 결함이 있으며, 이런 결함은 나중에 고쳐져야 하는데, 프로그래머가 다른 project에서 일을 하게 되어 code에 대하여 잊게 된다.
다른 잇점은 unit test가 code의 디자인이나 object model에 긍정적인 영향을 미치는 것이다. 많은 designe상의 문제점은 객체를 처음 작성할 경우 programmer가 나중에 사용하기 힘든 것으로 판명나는 interface를 만드는 결정을 하는 것이다. 그 interface를 사용하기 위한 code를 작성할 때가 되면, 객체는 이미 만들어져 있고, 실제로 사용하기 위한 방법을 포함시키는 것이 힘든 경우가 많다. Unit test는 해당 object를 사용하는 code의 작성에서 시작하도록 하여 object에 대한 coding이 시작되기 전에 나쁜 interface를 쉽게 판별할 수 있도록 한다.
완벽한 Unit test suite가 있으면 refactoring을 매우 쉽게할 수 있다.
Unit testing은 더 좋은 S/W 를 개발하기 위한 효과적인 방법이다. TDD는 표준 개발 방법에 비하여 결함이 적은 code를 작성할 수 있는 경우가 많으며, TDD를 이용할 경우 이전에 비하여 code를 더 빨리 개발할 수 있는 것을 발견하는 경우가 많다.
TDD는 발상의 전환이 필요하다. Code를 작성한 후 test를 어떻게 할 것인가 궁리하여 test를 작성하는 대신 매일, 매순간 software를 만들때마다 test를 작성한다. Design의 상세 사항을 종이에 문서의 형태로 남기는 대신 이를 code로 작성하여 test하여 볼 수 있도록 한다. 전체 시스템을 완벽하게 디자인하기 위하여 노력하는 대신 test를 이용하여 design을 도출한다.
단계:
- 약간의 새로운 기능을 필요로 하는 test를 작성한다.
- 그 기능이 아직 구현되지 않았으므로 test가 실패하는 것을 확인한다.
- 그 test가 통과되도록 하는 최소한의 code를 작성한다.
- Code를 refactor하여 현재까지의 기능을 만족하는 가장 단순한 디자인이 되도록 한다.
규칙:
- 문제가 될만한 모든 경우를 test한다.
- Test를 먼저한다.
- 모든 test는 언제나 100% 통과되어야 한다.
장점:
- 각 모듈이 독립적으로 test될 수 있는 code가 작성된다. Test를 염두에 두지 않은 code는 종종 서로 복잡하게 얽혀 있으며, 이는 디자인이 잘못된 것을 나타낸다. Test를 먼저 작성할 경우 test를 독립적으로 쉽게 하기 위하여 상호 연관성을 최소화한 code를 작성하게 된다.
- Test가 전체 system에 대한 문서의 역할을 한다. Test는 각 개발된 code를 처음, 직접 사용하는 예이며 이는 개발자에게 개발된 class을 어떻게 쓰는지를 직접적으로 보여주는 예가 된다.
- TDD의 정의대로 개발된 system에 자동적으로 test된다.
- 개발이 적당한 정도의 보조로 유지된다. Test에 약간의 기능을 지정하고, 이를 만족할 수 있는 약간의 code를 작성하고, 작성된 code를 정리한다. 이를 반복하며 약간은 수분 이내에 할 수 있는 정도를 말한다. 지원하는 기능 측면에서 code가 거의 일정한 속도로 지속적으로 개발된다.
개발 생산성과 개발자의 역량을 높이는 데 도움이 된다고하여 개발자들 사이에서 많은 주목을 받고 있는 TDD(Test Driven Development).
여러 장점들 덕에 단시간에 많은 개발자들의 관심을 받고 있으며, 다양한 프레임워크와 툴들이 개발되며 인기를 더해가고 있는 개발 방법론이기도 하지만
한편으론 실무에 적용하는데 미숙한 점이 있어 아직 현업에 적용하기엔 미숙한 점이 많아 일명 삽질이라 불리는 FNR(Fix And Run)과 병행하거나 TDD를 배제하는 개발자들도 있습니다.
이 글을 읽으시는 분들 중에도 TDD를 통해 프로젝트를 진행중이거나 진행해 본 개발자들이 많을 것입니다.
실무에서 얼마나 유용한 방법론인지와 어떤 문제점들이 있는지, 어떻게 보안하면 좋을지 등에 대해 함께 논의해 보고자 합니다.
여러분의 소중한 의견을 부탁드리겠습니다.
TDD 실전에 얼마나 적용 가능한가?이름 : 최종원 조회: 95 추천 : 459Refactoring 관점에서 테스트케이스는 매우 중요하기 때문에, 테스트 케이스를 확보한다는 측면에서 TDD는 정말 매력적입니다. 하지만, 실제로 적용하려고 하면 테스트를 위한 설계를 해야 한다는 점이 참 어려운 것 같습니다.
TDD가 실전에서 잘 쓰이기 위해서는 테스트 케이스 개발이 쉽고, 편리해야 하며(가능하면 자동화 되면 좋겠죠...) 테스트 설계에 대한 충분한 지식이 있어야 할 것 같습니다. 그냥 개발자들에게 테스트 케이스 만들고 개발해... 하면 막막하죠. 연습도 안된 상황에서는요...
TDD 실전에 적용하기엔 아직 어렵다에 한표..
TDD 실전에 얼마나 적용 가능한가?이름 : 김호범 조회: 47 추천 : 227PM,PL역활을 주로 하는 입장으로써, 품질과 공수 단축을 위해 적용하고 싶은 마음이 굴뚝 같습니다만, 이런 문화를 받아들이고 익숙한 개발팀이라면, 문제가 없지만, 여러 팀이나 임시로 투입된 인력으로 황당한 갑과 정치노름에 몰두해야 하는 대부분의 프로젝트 문화로 볼때 참 어려운 부분입니다.
이렇게 해보았자. 갑이나 수주업체(SI업체)에서 별도로 진행하는 형식적이고 차후에 참여하는 QA활동과의 괴리도 많은 회의감을 느끼게 합니다, 일은 점점힘들어지고 질은 계속 낮아지고, 참 난감함이 앞섭니다. TDD를 적용하고 싶어도 PMO조직이 거의 일방적으로 진행하는 일정에 맞추다보면, 일단 무식한 고객들에게는 화면이나 그럴싸한 모습을 보여주어야 하고, TDD의 성과는 비교적의 후반부에 가속화되기때문에 어려움점이 많을것이 자명합니다. 실제 현업에 개발을 진행하는 업체PM들이 아무리 의지가 있다고 해도 주관업체나 갑에서 의지가 없으면 힘들다고 생각합니다.
뭐, 한팀이나 회사내에서라면 얼마든지 가능하겠지만 말입니다. 결국 이런 프로젝트 시간에 쫒기나 보여주기식으로 강요되는 개인생활 반납, 휴일 반납하면서 몇개월 보내면 개발자에게 남는건 아무것도 없고, 영양가 없는 삽질에 회의감만 쌓이지요.