Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Test Driven Development (TDD)

Test Driven Development (TDD) 도입을 위한 여러 가지 생각 들
by

seung hak choi

on 19 November 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Test Driven Development (TDD)

TDD
Test Driven Development TDD 란? 전통적인 개발 방식 전통적인 개발 방식의 문제점? TDD 개발 방식 왜 어려운가? 결국 좋지만 오래 걸린다? 익숙해 지는데 걸리는 시간은? 어려운데... 노력 대비 효과는? 얻을 수 있는 것 꼭 TDD 로만 얻을 수 있는 건가? 부정적인 시각 너무 좋은 얘기만 하는 거 아냐? TDD 도입을 위한 도움말 원칙은 없다. 시연 TDD는 어렵다? 테스트가 개발을 주도 (Test Driven Development) 테스트를 먼저 시작 하는 것 좋은 분석기법 좋은 설계기법 테스트에 대한 기법이 아니라 개발 방식에 대한 이론 TAD (Test-After Development) 요구사항 확정 분석 설계 개발 테스트 출시 각 단계를 분리하는 것의 문제점 각 단계가 모두 잠재적 병목이다.
앞 쪽이 완성될 때 까지 뒤 쪽은 기다려야 한다. 시간이 지날 수록 소스는 더럽혀지고 유지 보수는 어려워진다. 수시로 테스트를 하지만 버려지는 테스트 코드. 실제 개발 보다 테스트가 더 길어지는 상황 발생 끔찍한 수준의 코드를 작성한 후 이를 어떻게 테스트 할지 고민한다. 잘 못된 이론을 붙들고 테스트를 통과할 수 있도록
기교를 부린다. 대략적인 설계 개발 할 기능 선택 테스트 목록을 작성 테스트 코드 작성 개발 코드 작성 성공 확인 Refactoring 수 많은 난관에 부딪히고 많은 생각을 하게 된다. 무엇부터 해야 하지? 테스트 코드 먼저라니.. 어색하다. ㅠ 이걸 어떻게 테스트해? 뭔가 할 때 마다 어려운 것을 하는 것 같고... 부담스럽다. 익숙해 지기 까지 시간이 오래 걸린다. 사고 방식의 전환이 필요 테스트 먼저!!! 여러 가지로 개발 환경이 불편하다 무엇을 테스트 하지 ? 언어 본연의 특성에 대한 이해 부족 바른 길이 결국 가장 빠른 길 TDD 에 익숙해 지면 결국 가장 빠른 길이 될 것이다. 사티어 변화 모델 버지니아 사티어(Virginia Satir)라고 가족 치료 전문가가 만든 변화 모델 http://agile.egloos.com/4876792 2. 저항이 시작 (Resistance) 3. 혼란 (Chaos) ▲ 전환적 착상(Transforming Idea) 4. 통합과 수련 (Intergration) 5. 안정적 상태(New Status Quo) 1. 현상태 (Late Status Quo) ▼ 외부 요인 (Foreign Element) 돈오점수 문득 깨달음에 이르는 경지에 이르기까지에는
반드시 점진적 수행단계가 따른다는 말 http://terms.naver.com/entry.nhn?docId=1083681&mobile&categoryId=200000083 도입사례 처음에는 조금 반감이 생기는 것 같더니 (저항이 시작) 두 번째 하려고 할 때의 반응은 "이런거 하지 말자" 였다. 우리는 사티어 변화 모델 2번(저항)에서 4번(통합과 수련)까지 오는데
1년이 걸린 것 같다. http://opentypo.wordpress.com/2012/09/22/new-status-quo-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%EB%8A%90%EB%82%8C/ 얻는 것에 비해 큰 노력이 드는 것은 아니다. 노력 효과 어떻게 테스트 하지 ? 고민해 왔던 것들에 대한 많은 답을 얻을 수 있다. 군더더기 없이 설계된 코드 변화에 대처할 수 있는 유연한 코드 쉬운 유지 보수 완성도 높은 코드 품질 개발 코드의 무결성 보장 ... 응집도는 높고 결합도는 낮은 설계 가장 이상적인 설계 응집도(Cohesion) 높은 것이 좋다. 한 가지만 순도 높게 담당함을 의미 하나의 Class 는 하나의 기능만 담당
하나의 Method 도 하나의 기능만 담당 응집도 결합도 결합도(coupling) 낮은 것이 좋다. 서로 다른 기능이 얽혀서
상호 의존도가 높은 정도 TDD 가 자연스럽게 유도해 줄 것이다. 동작하는 최소한의 코드 Simple is Hard (PHP 창시자 Rasmus Lerdorf) http://talks.php.net/show/korea09/2 '경험과 복잡도에 대한 상관관계' 나에게 문제가 생겼다고 도움을 요청할 때마다 내가 하는 일은 코드를 지우는 것이었다. 기술적 채무 의 최소화 http://www.ibm.com/developerworks/kr/library/j-eaed1/index.html#resources 기술적 채무는 신용 카드 부채와 비슷 나중에 시간이 날 때 다시 고칠 계획으로 임시 방편을 적용 기술적 채무 Good Design Bad Design 깔끔한 설계를 유도해서 기술적 채무를 줄여준다. 변화에 유연하게 대처 가능 "변하지 않는 것은 모든 것은 변한다는 것." 요구사항은 계속 변할 것이다. 유지보수가 용이 회귀 테스트 (Regression testing) "내가 이걸 고치면 다른 부분에서 오류가 발생하지 않을까?" 수정 후에도 의도대로 작동하고 있음 확신 비교적 흐름이 깨지지 않고 개발에 집중 할 수 있다 무엇을 테스트 할 지 작성된 목록을 통해 알고 있다. 지금 개발해야 하는 건 몇 줄 되지 않는 간단한 코드 언제든 자리로 돌아와 목록을 보고 개발하면 된다. 순환 복잡성(Cyclomatic Complexity)을 낮춘다. 코드 품질의 지표로 사용 "분기문 개수 + 1" 로 계산 while, for, if, case ... 의미적으로는 실행 경로의 개수 분기문이 많으면? 분기문 = 테스트해봐야 하는 경로의 개수 코드가 복잡하다는 의미 필요한 테스트가 그 만큼 많다는 뜻 대개는 10 이하가 양호 높은 커버리지 보장 코드의 보장 범위를 의미 코드 품질의 보장 커버리지를 향상 시키는 방법 더 많은 테스트를 작성 하는 것
로직을 단순화 하는 것 TDD가 자연스럽게 로직을 단순화 시킨다. TDD 를 하지 않아도 모든 것을 할 수 있다. 하지만... 어렵다. 하나하나 가 모두 큰 주제 오랜 경험과 학습, 노하우가 필요하다. 어쩌면... 평생 답을 얻지 못 할 수도 있다. TDD 는 이 모든 것을 자연스럽게 유도해 준다. html tag 의 변경 요구 사항이 기존 Javascript Test
코드들을 못쓰게 만든다? 이것은 html tag 의 구조 와 js code 의 결합도가 높다는 의미 그럼 1가지 로직을 구현하고 즉시 테스트 코드를
구현하면 되는거 아닌가? 이미 생각하고 구현한 다음 거기에 맞춰 테스트 코드를 작성하는 것은 생각의 전환을 가져오지 못한다. 이것은 기존의 개발 방식과 다르지 않다 테스트 케이스랑 같은 거 아닌가? 테스트 케이스?
프로그램의 각 부분을 고립 시켜서 각각의 부분이 정확하게 동작하는지 확인
대부분의 효과가 TDD 와 같다. 진행 순서로 봤을 때 테스트 케이스는 전통적 개발 방식과 다르지 않다.
(개발 => 테스트) 좋은 설계를 유도 해준다고 해서... 대충 설계를 했다가 낭패를 봤다. 설계를 대충 해도 되는 것은 아니다. 좀 더 나은 설계가 되도록 유도해 주는 것. 모든 기능에 대한 테스트를 작성 하려면 엄청난 시간이 필요하다? 모든 개발자는 테스트를 한다. 다만, 버려질 뿐이다. 테스트 코드 작성으로 시간이 필요한 것이 아니고 무엇을, 어떻게 테스트 할까? 에 대한 고민 때문에 시간이 필요할 거 같다. 그렇다면 추가 적인 시간 없이 TDD 가 가능한가? 초기에는 시간이 많이 필요할 거 같다. 하지만, 익숙해 지면 해소 될 수 있다고 생각한다. 너무 좋다고 만 하는 것 같다? 증거를 수집하지 않으려고 노력했다. 좋지 않으면 왜 좋지 않은지를 준비하려 했다. 한 가지에만 집중하자. 지금 테스트 하는 코드에만 집중하자. 코드를 작성하다 뭔가 떠오면 할일 목록에 올리자. 우선 테스트 중인 것을 완료 하고 나중에 확인해도 된다. 무엇을 테스트 해야 할 지 모르겠다면? 내가 무엇을 만들지 잘 모른다는 것을 의미. 구현 할 명세 목록이 명확해 질 때 까지 좀 더 작게 나누자. 작게 생각하자 작은 것은 다루기 쉽다. 작은 것으로 큰 것을 만드는 것이다. "테스트를 작성할 수 있는 가장 간단한 것은?" 식별 가능한 하나의 태스크를 수행하는 메소드로 프로그램을 나눈다. 그러면 자연스럽게 프로그램이 다수의 작은 메소드로 나뉜다. 각각의 테스트는 다른 테스트와 완전히 독립적이어야 한다. 그럼 테스트 단위가 짧아지며 그 과정에서 더 많은 정보가 노출되고 에러없는 코드를 작성할 수 있다. 너무 멀리 생각하지 말자. 개발자는 너무 많은 추측성 코드를 양산하는 경향이
있다. 은총알은 없다. 코드에 의도를 드러내자 의미 있는 Naming 은 주석이 필요 없을 정도로 유익하다. (최대 4개 정도의 단어 조합) 의도가 분명하지 않은 코드는
method 로 분리해서 Naming 으로 의도를 드러낸다. Mock 사용은 최소 한으로 모의 객체 (Mock Object) 실제 모듈 사용이 어려울 때
실제 모듈을 흉내 내는 가짜 모듈을 작성하여
테스트에 사용하는 방법 Mock 의 원형이 변경 되어 발생 할 수 있는
에러는 테스트 코드로 찾을 수 없다. 불가피한 경우에만 사용 하자. TDD 개발을 위한 환경을 갖추자. 부담 스럽지 않은 개발 환경 구축이 필요 한 것 같다. JCat, Qunit, Proejct 별 JSCat Build 연동 ... Local 환경 구축
http://goo.gl/76q68 TDD 개발은 여러 가지로 너무 불편 했다. Local 에 JSCat Build System Setting 하기 Browser 자동 새로고침 테스트 코드 수정시 마다 Browser 자동 새로고침
ex. sublimeText2 + liveload 짝 프로그래밍 (Pair Programming) TDD 개발 감각을 익히는데 도움이 된다. TDD 기본 원칙대로 개발 하려고 집착하지 말자. 일단 개념을 잡고 상황에 따라 응용을 하면 된다. 유연하게 대처하자 ... 밥먹을 땐 밥만 먹으면 응집도가 높은 것 포크없이 밥 못 먹으면 결합도가 높은 것 [ONLY FORK]
Full transcript