Is Tdd dead?
장재휴
등장인물
- DHH (David Heinemeier Hansson)
- 루비온레일즈 창시자
- Kent Beck
- 소프트웨어 패턴 운동의 선구자 중 한 명
- 리팩토링과 TDD를 소개하고, xUnit 유닛테스트 프레임워크를 만듬
- Agile Methodology중 가장 널리 알려진 XP(Extreme Programming)의 아버지
- Martin Fowler
- 소프트웨어 설계에 대한 수많은 이론적인 개념 정립과 사례 창출
- Refactoring의 개념을 정립함.(REFACTORING 저자)
- 객체지향 분석/설계, UML, 패턴, XP, agile등 다방면에 절대적인 영향력이 있음
tdd
Test Driven Development
Step 1 – TEST RED
Write the test, without any code written yet
RED: test fails
(compilation errors are considered failures as well)
Step 2 – TEST GREEN
Make test work as quickly as possible
GREEN: test passes
(code satisfies the test assertions)
Step 3 – CODE REFACTOR
Keep the test code unchanged
Rework the implementation to make it
clean, DRY, flexible
GREEN: new code passes the test
(reworked code behaves exactly as before)
Unit Test
Test-First
사건의 시작 - DHH
많은 사람들이 TDD를 광적으로 신봉하고 있다.
하지만, TDD는 시스템을 쓸데없이 복잡하게 만든다
난 TDD를 하지 않겠다. 대신 좀 더 의미있는 테스트를 하겠다.
TDD가 소프트웨어 개발에 가져온 기여에 존경을 표한다.
TDD는 역사에 중요한 발자취를 남겼다.
하지만 지금은 그 다음을 향해 가야 할 때다.
테스트여 영원하라!
Kent의 맞수
TDD는 여전히 중요하다!
let's start DISCUSSION - martin
-
Skype를 통해 discussion이 진행됨 - Martin
- public conversation을 제안함 - Kent
-
구글 행아웃을 통해 5번의 public discussion이 진행됨
1: TDD and Confidence
2: Test-induced design damage
3: Feedback and QA
4: Costs of Testing
5: Answering Questions
#1 - TDD and Confidence
We talk about our varying experiences with the flow of TDD, and the way TDD and self-testing code are often confused
Confidence
하지만...
conversation flow(#1)
TDD가 주는 효과 중 중요한 것 : "Confidence"
TDD로 개발하든, regression test 방식으로 개발하든 상관없다.
단지 스타일의 문제다- Kent
하지만 TDD는 분명 어떠한 흐름을 만들고 있다.
많은 사람이 에너지를 낭비하면서까지 TDD를 한다.- David
trade-off다. 할만할 가치가 있을때 하면 된다. . .- Kent
CONVERSATION FLOW(#1)
다시 요점으로 돌아가서... David의 이슈는 아래 2가지이다
1. heavy mocking in TDD
2. difference of TDD and self-testing code- Martin
많은 사람들이 mock-heavy style 방식을 더 성숙한 코드라 생각한다.
특히 isolated unit test는 전반적인 디자인을 바보같이 만든다.- David
to be continue...
#2 - Test-induced design damage
David feels that using TDD leads to approaches such as hexagonal rails that is test-induced design damage due to the complexity of excessive indirection. Kent thinks it's less about TDD and more about the quality of design decisions.
it's about HOW TO GET FEEDBACK
참고: Hexagonal architecture
CONVERSATION FLOW(#2)
이슈 제기1. Can TDD lead to design damage?2. Is the resulting damage really damage? How do we judge if a design is damaged or not?- Martin
TDD가 디자인을 망친 코드를 샘플로 제시 - gist- David
TDD 때문이 아니다 vs. TDD 때문이다 (난상토론). . .- Kent, David, Martin
it's not about TDD it's about HOW TO GET FEEDBACK- Kent
#3 - Feedback and QA
We discuss the various ways in which we get feedback while programming and the role of QA in providing feedback to developers.
FEEDBACK
CONVERSATION FLOW(#3)
TDD는 trade-off를 수반한다.TDD는 확실한 feedback을 즉가적으로 받는 것이 목적이다.trade-off를 생각할때 고려해야 할 것은 다음과 같다.
- Frequency
how rapidly do we want our feedback?
- Fidelity
how accurate do we want the red/green signal to be?- Overhead
how much are we prepared to pay?
- Lifespan
how long is this software going to be around, which is probability as well as time.
- Kent
CONVERSATION FLOW(#3)
feedback을 통해 얻을 수 있는 것
- Is the software doing something useful for the user of the software? Sometimes tests help with this (eg payroll calculations) and sometimes not (eg html rendering).
- Have I broken anything? "This is where self testing code… is such a lifesaver." I want to see every test fail at least once.
- Is my code-base healthy? This so I can continue to build things quickly. This element gets more tricky when you're not sure who will take over the code.
- Martin
CONVERSATION FLOW(#3)
TDD를 통한 feedback의 문제점1. TDD는 QA를 등한시하게 만든다2. 아무도 TDD의 cost는 생각하지 않는다.- David
전통적인 QA의 역할은 없어졌다.
90년대 이후의 가장 큰 변화는 QA의 역할이 줄어들고, script test가 등장한 것이다. 그 결과 많은 Startup이 생겨났다.- Kent
그래도 QA는 중요하다.모든 test를 통과했다고 해서, production에서도 그것을 기대하면 안된다.고객의 전화나 QA의 결과도 feedback loop다.TDD는 결국 개발자가 예상한 시나리오만 통과했을 뿐이다.- David
CONVERSATION FLOW(#3)
TDD 관점에서 on-call feedback은 개발자에게 test를 작성하지 않았다는 것을 보여준다.(그래서 facebook에선 모든 개발자들이 고객응대를 해야 한다)
“'더이상 실수는 없다'라고 생각하는 것이야말로 진짜 실수고, 그것은 성장을 멈추게 한다. 그리고 세상은 당신이 아무것도 망치지 않은 척 하도록 놔두지 않는다.”- Kent
QA feedback loop의 관점에서 여전히 중요하다.costs of testing은 다음에 얘기하자!- Martin
#4 - Costs of Testing
We discuss some downsides of testing and TDD
Test를 위한 Test는 하지 말자
Test를 얼마나 해야 하나? "그때그때 다르다"
CONVERSATION FLOW(#4)
Over-Testing에 대해 얘기해보자
(over-testing의 예: "failing test 없이는 단 한줄의 코드도 짜면 안된다!")- David
그것은 test에 대한 cost가 아니다. 단지 안정감을 갖기 위한 것일 뿐이다.
TDD가 항상 over-test를 야기시키진 않는다.- Kent
feedback을 주지 않는 test는 날려버려라! (참고: Delta Coverage)
(예: zero delta coverage, refactoring 후, etc)
"ratio of lines of test to lines of production" 같은건 사이비다.
test를 얼마나 해야 하나? 대답은 "그때그때 다르다"- Kent
CONVERSATION FLOW(#4)
무언가를 변경해야 할 때, 실제 behaviour를 변경하는 것보다 test를 변경하는데 더 많은 노력이 든다면 over-testing이다.
자신의 팀에 맞게 TDD를 적용하라.- Martin
CONVERSATION FLOW(#4)
예전에 documentation이 code보다 더 중요하다고 생각했던 것 처럼, 요즘에는 functional code보다 test code가 더 중요하다고 생각하는 사람들이 있다.
아마 TDD에서 refactor part를 덜 중요하게 생각하는 사람들일 것이다.- David
나는 그냥 production 코드를 날려버린다. 그런다음 다시 짠다.
새로짠 코드가 문제 없다는 것은 test가 보장해준다.- Kent
나는 둘 중 어느것이 더 중요하다고 생각하지 않는다.
종종 user를 support하는 것보다 test에 더 중점을 두기도 한다.
나도 깔끔한 코드를 짜는데 짜릿함을 느낀다. 하지만 더 스릴을 느낄때는 새로운 기능을 추가할때다. 결국 이것이 clean code를 만든다. 하지만 이렇게 clean code를 만드는 것과 단순히 짜릿함을 느끼는 것에는 반드시 차이가 있다- Martin
CONVERSATION FLOW(#4)
test speed, coverage, ratios. 이런것에 대한 우선순위를 낮추어야 한다.
이것은 함정같은 것이고, 일종의 잘못된 신호이다.
production code보다 test를 자랑하는 것을 보면 화가 난다.
TDD의 중요성을 널리 퍼뜨리기 위해 이런 방식이 사용되곤 했었다.
하지만 이젠 이것을 극복해야 한다.
TDD는 여전히 매력이 있지만, 그것이 절대적이진 않다.- David
#5 - Answering Questions
We answer questions from our viewers: what open-source examples of TDD exist, what changes would make us change our use of TDD, and how well it works for inexperienced developers. We finish by summing up our view of the health of TDD.
1: what open-source examples of TDD exist
프로젝트 상황에 따라 다르다
과학처럼 접근해서는 안된다. 명백히 측정할 수 없다.
일반적인 답을 찾을수는 없을 것이다.
하지만 개개인은 그 답을 찾아내야 한다
2: what changes would make us change our use of TDD
TDD는 confidence 문제 해결을 confidence에서 시작하게 해준다.
그리고 문제를 잘께 쪼갤수 있게 해 준다. 그것이 어렵다고 포기하지 마라- Kent
TDD에 적합한 application이 있고, 아닌 application도 있다.- Martin
나도 TDD를 통해 testing에 입문했고 TDD를 여전히 좋아하지만,
많은 MVC Web application에는 적합하지 않은 것 같다.
하지만 TDD가 효율적이지 않다는 말은 아니다.
그리고 TDD를 안한다는 것은 self-testing을 하지 말라는 말도 아니다.- David
2: WHAT CHANGES WOULD MAKE US CHANGE OUR USE OF TDD
일단은 TDD를 시작하고, 그것이 너무 과도하다고 느껴진다면
너 자신에 맞게 만들어라. 그것이 한단계 깊이 들어가도록 할 것이다
TDD가 self-testing의 gateway다.- Martin
나와 David의 경험은 다르다.
나는 새로운 idea를 구현하거나 특정 protocol을 만드는 일을 많이 했다.
TDD는 quickly feedback이 가능하도록 해 주었고,
API를 만드는데 많은 도움이 되었었다.
나에게도 TDD가 적합하지 않은 케이스도 있었다
- Kent
3: how well it works for inexperienced developers
TDD가 great result를 보장하진 않는다. 좋은 design은 경험이 필요하다.
하지만, TDD를 적용하기 전과 후를 비교해보라.
TDD는 프로그래밍의 좋은 시작점이다.- Martin
나도 TDD로부터 test의 가치를 알게되었다.
하지만 문제는 discussion을 충분히 하지 않는다는 것이다.
사람들은 TDD에 대해 떠들어대지만, 정작 그들은 TDD를 제대로 안한다.
사람들은 TDD에 자신만의 무언가를 추가했고, 너무 멀리까지 와 버렸다.
RESET 버튼을 눌러야 할 때다! 원래 모습 그대로 돌아가자!
“TDD is dead”는 지금의 이러한 변종에 대한 고발이었다.- David,
Reboot! first principle로 돌아가자 - Kent
3: HOW WELL IT WORKS FOR INEXPERIENCED DEVELOPERS
TDD뿐만 아니라 XP, Ruby, Agile,, 이런것들도 마찬가지다 - David많은 사람이 agile을 말하지만, 그들은 진짜 agile을 하고 있지 않다. - Martinagile을 하고 있다는 사람들도, 각자 딴소리 하는 경우가 많다. - David그래서 David에게 감사한다. TDD를 다시 다듬을 수 있게 되었다 - KentRails도 마찬가지. Rails application을 보고 경악을 할때가 있다 - David기술이 오용되는 경우가 많다. 기본에 대해 꾸준히 학습해야 한다. - Kent
Reboot. 새로운 Language를 선택하는 것이 도움이 될 수 있다(Ruby)
Functional Programming도 또하나의 Reboot가 될 수 있다- David
Ending
TDD는 죽지 않았다. 하지만 David가 여기에 불을 지폈고, 이로인해 TDD는 거듭날 것이다. - Kent
TDD의 단점에 대해 아무도 얘기하지 않고 있어서 이 discussion을 시작했다.
난 TDD가 정말로 적합한가? 적합하지 않은가?를 말해보고 싶었다.
하지만 TDD에 대한 의문으로 self-testing의 중요성까지 잃어버리면 안된다.- David
self-testing code는 중요하고, TDD가 가치를 발휘하는 context가 있다. Software에 몸담고 있다면, 항상 깊이 생각하고 적용하고 훈련해야 한다.
맹목적으로 따라해서는 안된다.
너와 너의팀에 맞는 방식을 찾아야 한다.
우리가 하는 것은 과학이 아니다. 우리 자신만의 경험으로 일해야 한다.- Martin
Is Tdd dead?
By bbugguj
