21. テスト駆動開発の効果
IBM
ドライバ
Microsoft
Windows
Microsoft
MSN
Microsoft
VisualStudio
チーム人数 9 6 5-7 7
コード量(KLOC) 41.0 6.0 26.0 155.2
開発規模(人月) 119 24 46 20
欠陥数
(TDD未使用に対
する)
61% 38% 24% 9%
開発時間の増加
(管理者の見積)
15~20% 25~35% 15% 20~25%
Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, Laurie Williams
“Realizing quality improvement through test driven development: results and experiences
of four industrial teams” 2008
http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf
22. 保守性への影響
※1 保守期間(260日間)中、変更要求の対応にかかった工数の平均
"The effectiveness of test-driven development: an industrial case study"
(Tomazˇ Dogsˇa • David Baticˇ , Software Qual J (2011))
生産性
(行数/工数)
保守性 ※1
(工数/変更件数)
プロジェクトA
(非TDD)
2.3 84
プロジェクトB
(非TDD)
2.5 80
プロジェクトC
(TDD)
1.8 59
23. TDDの効果の研究をまとめた研究
"Effects of Test-Driven Development: A Comparative
Analysis of Empirical Studies" Simo Makinen and Jurgen
Munch, 2013
• 既存の実証研究を調査し、10の内部・外部品
質評価項目で、各研究の結論を整理した
• TDDは欠陥の作り込み(introduced defects)を
減らし、メンテナンスしやすいコードを産む
• TDDで実装されたコードは、部分的に、サイ
ズが小さく、複雑度が低い場合がある
• メンテナンスがしやすくなるものの、初期開
発では時間がかかる
30. A Comparative Case Study on the Impact of Test-Driven Development on Program Design and Test Coverage
Maria Siniaalto and Pekka Abrahamsson, ESEM, 2007
http://se.inf.ethz.ch/old/teaching/2010-S/0276/slides/pletikosa.pdf
結合度: TDDが悪く見えるけど微妙
凝集度: TDDの経験が足らない
テストカバレッジ: TDDは非常に良い
38. Additionally…
TDD damages or breaks an architecture
TDD people have forgotten the knowledge of testing and
quality (as in Quality Assurance)
So TDD has little or even negative effects on quality
TDDはアーキテクチャを破壊する
TDDやアジャイルの人は
テストや品質保証の知識が足らない
41. What are the possible meanings of TDD?
1) Test Driven Development: the idea of writing your code in a test first manner. You
may already have an existing design in place.
2) Test Oriented Development: Having unit tests of integration tests in your code and
write them out either before or after our write the code. Your code has lots of tests.
You recognize the value of tests but you don't necessarily write them before you write
the code. Design probably exists before you write the code
3) Test Driven Design(the eXtreme Programming way): The idea of using a test-first
approach as a fully fledged design technique, where tests are a bonus but the idea is to
drive full design from little to no design whatsoever. You design as you go.
4) Test Driven Development and Design: using the test-first technique to drive new
code and changes, while also allowing it to change and evolve your design as an added
bonus. You may already have some design in place before starting to code, but it could
very well change because the tests point out various smells.
http://osherove.com/blog/2007/10/8/the-various-meanings-of-tdd.html
「TDD」は4通りに使われている(少なくとも)
テストファースト テスト重視 設計手法 開発(+設計も)
人によって違う意味になっている
42. What is TDD?
Make sure the code works
Always have a goal
Continuous care of cleanness
TDDとは
動くコード
身近なゴール
きれいに保つ
43. What is TDD, fundamentally?
Feedback if the code works
Feedback from user’s viewpoint
Continuous feedback of what is clean
そもそもTDDとは
動くかどうかのフィードバック
ユーザ視点からのフィードバック
何がきれいかのフィードバック
44. Feedback=Learning
You do learn, throughout the course of a project,
about the product, technology, design, team, etc.
TDD generates many points of learning
フィードバックとは学び
学ぶことはたくさんある
TDDは学びのポイントを作る
45. Learning ≠ Guarantee of Success
Planning for learning is important
Many things are hard to learn by TDD
There are cases TDD is not effective / feasible
学ぶだけでは成功しない
何をどうやって学ぶか、計画せよ
TDDだけでは足らない
50. Practice required
You must learn and practice to be
effective
“intensively trained for 3 weeks before project C
starts” (Tomazˇ Dogsˇa and David Baticˇ, 2013)
素振り重要
53. My experience
I do TDD these days, but not 100%
I do test first rather sparingly
I confess I don’t write code much anyway …
I know when I should do TDD and not
今でもTDDするが100%ではない
(実のところあまりコード書いてない)
TDDをいつ使うか 直感が働く
54. My experience
TDD is not effective when you have no idea
what you want to build
Create the big picture by hacking, spiking,
BDUF, architecting, anyway you can do
In this phase, anything you write are
throwaway code
TDD works after you have clear goals
何を作るか見当も付かないとTDDは非効率
まず全体像(ハック/アーキテクチャ/事前設計)
目的がはっきりしていればTDDは有効
55. My experience
API, framework or library – TDD works very well, both designing
exposed interfaces and internal structures.
Simple Web applications – can do but often feels cumbersome. BDD
style works best.
Complex algorithm – no TDD. Isolate its complexity and define external
spec. It’s good if the specs are automated. Then design upfront.
You may build up algorithm step by step with TDD, but prepare to discard the
code once it’s complete. There’s a chance some of the tests can be reused.
API、フレームワーク、ライブラリ→TDD!
簡単なWebアプリ→TDDよりBDD
複雑なアルゴリズム→ちゃんと設計
56. My experience
With inadequately skilled people – TDD helps generating “better”
quality code, i.e. at least normal cases run. Test code reviews by senior
engineers works great. Abandon hope for really good output.
Give them trainings. Those people have a lot of chance of improvement and
TDD helps learning.
Highly effective team – they say they do TDD but not 100% of the time
and you can trust them of the output. It’s the best.
スキルが低い開発者→TDDのほうがマシだが、
しっかり面倒見る必要あり
すごいチーム→放っておいてよい、
TDDもちゃんと使える
57. My experience
Anything you are not familiar – start with TDD and
proceed with caution. As you learn stuff, you can
decide what techniques works best.
Throwaway code – Do anything you like. I like
occasional TDD.
よく知らないもの→TDDで始めて、
わかってきたところで判断する
一度切りのコード→ご自由に、
TDD使うこともあるよ
59. Introducing Joseph
Founder and Architect, The Refactory, Inc.
Pattern enthusiast, author and Hillside Board
President
Author of the Big Ball of Mud Pattern
Adaptive systems expert (programs adaptive
software, consults on adaptive
architectures, author of adaptive
architecture patterns, metatdata maven,
website: adaptiveobjectmodel.com)
Agile enthusiast and practitioner
Business owner (leads a world class
development company)
Consults and trains top companies on design,
refactoring, pragmatic testing
Amateur photographer, motorcycle
enthusiast, enjoys dancing samba!!!
59
Joe Yoder (ジョー・ヨーダー)
The Refactory, Inc.
パターンの人 PLoP開催
60. 継続可能な
アーキテクチャ
Copyright 2014 Joseph W. Yoder & The Refactory, Inc.
Joseph W. Yoder -- www.refactory.com
https://www.slideshare.net/yattom/ss-39226174
67. Don’t Do:
Become religious nor naysayer
Mandate TDD
Believe everything you hear
Numbers don’t lie, people do
TDDの信仰も拒絶も良くない
TDD必須とか止めよう
言われたことを盲目的に信じない
70. Do:
Find out your impediments
Try TDD for solving an impediment
With enough training and practice
Evaluate and make it better
Continue
まず障害物を見つける
解消のためTDDを試す(練習も忘れずに)
結果を評価して改善する
それを繰り返す