Hey It’s not my TDD!安井力 / やっとむ

「それ俺のTDDとちがう！」字幕 やっとむ

Copyright©2014,2015 安井力/やっとむ All rights reserved.

安井 力 / やっとむ

プログラマーJava Python Ruby JavaScript

テスト駆動開発

アジャイルコーチワークショップ 現場導入 技術支援

コンサルタントモデリング ユーザーストーリー

twitter:@yattom facebook:yattomgithub:yattom bitbucket:yattom

TDDBCAgile Academy

次回 11/30(月) 絶賛募集中！

メイン講師和田卓人

サポート(予定) 安井力太田健一郎

t-wada said…

「ＴＤＤのの目的は健康」

TDDとは

「動作するきれいなコード」、ロン・ジェフリーズのこの簡潔な言葉は、TDD(テスト

駆動開発)の目標である。動作するきれいなコードは、あらゆる理由で価値がある。

─ Kent Beck

動作するきれいなコードとは？

• 動作している

• バグ対応も、追加変更も容易である

• 作業が予測可能である

• チームに信頼が生まれる

動作する、きれいなコードへ

きれい

汚い

(すぐには)動かない 動作する

動作する、きれいなコードへ

きれい

汚い

(すぐには)動かない 動作する

二つの道がある

TDDのサイクル1. 次の目標を考える

2. その目標を示すテストを書く

3. そのテストを実行して失敗させる(Red)

4. 目的のコードを書く

5. 2で書いたテストを成功させる(Green)

6. テストが通るままでリファクタリングをおこなう(Refactor)

7. １〜6を繰り返す

TDDを支えるツール

Unit Test Frameworks

xUnit (JUnit, PHPUnit, NUnit, Pytest, …)

RSpec

Mocha

IDE, Refactoring tools

Eclipse, IntelliJ

Visual Studio

Continuous Build / Integration

Jenkins

Travis参考: TDD／BDDの思想とテスティングフレームワークの関係を整理しよう(きょん) http://www.atmarkit.co.jp/ait/articles/1403/25/news033.html

振る舞い駆動開発(BDD)

振る舞いを「実行可能な仕様」として記述

振る舞い＝機能的な外部仕様

システム全体として提供する機能にフォーカス

Webではブラウザ操作が前提

ユーザーとのコミュニケーションツールとしての期待

BDD向けのツール

振る舞いの記述 (Given/When/Then) RSpec

Cucumber, Turnip

Behat

JBehave

Jasmine

Web/ブラウザ操作 Selenium WebDriver

Geb

コミュニケーション Fit / FitNesse

振る舞い記述の例

メールを検索する前提 (Given)“yattom”としてログインしている

テスト用メールを100件受信している

受信ボックスを表示している

もし (When)「エラー」を検索する

ならば (Then)「エラー」を含む15件が一覧表示されること

振る舞い記述の例

メールを送信する前提 (Given)“yattom”としてログインしている

受信ボックスを表示している

もし (When)yattom2宛にメールを送信する

ならば (Then)送信済みボックスにメールがあること

yattom2がメールを受信していること

使われてる?

0

10

20

30

40

50

60

70

80

90

2007 2008 2010 2011 2012 2013

アジャイルプラクティスを使っている割合(%)

Daily Standup Unit Testing Retrospectives

Continuous Integration TDD Pair Programming

State of Agile Survey (VersionOne)http://stateofagile.versionone.com/

使われてる?

IPA 情報処理推進機構アジャイル型開発におけるプラクティス活用事例調査http://www.ipa.go.jp/sec/softwareengineering/reports/20130319.html

テスト駆動開発の効果

IBMドライバ

MicrosoftWindows

MicrosoftMSN

MicrosoftVisualStudio

チーム人数 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” 2008http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

保守性への影響

※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

TDDの効果の研究をまとめた研究

"Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies" Simo Makinen and JurgenMunch, 2013

• 既存の実証研究を調査し、10の内部・外部品質評価項目で、各研究の結論を整理した

• TDDは欠陥の作り込み(introduced defects)を減らし、メンテナンスしやすいコードを産む

• TDDで実装されたコードは、部分的に、サイズが小さく、複雑度が低い場合がある

• メンテナンスがしやすくなるものの、初期開発では時間がかかる

TDDの効果の研究をまとめた研究

やっとむ TDD 検索

動作するきれいなコードとは？

• 動作している

• バグ対応も、追加変更も容易である

• 作業が予測可能である

• チームに信頼が生まれる

t-wada said…

「ＴＤＤのの目的は健康」

ここらで一服

• みなさんのTDDの経験を教えてください

Which do you like?

https://www.flickr.com/photos/ooocha/3052091706/

Things got darker from here …

ところが……

A Comparative Case Study on the Impact of Test-Driven Development on Program Design and Test CoverageMaria Siniaalto and Pekka Abrahamsson, ESEM, 2007http://se.inf.ethz.ch/old/teaching/2010-S/0276/slides/pletikosa.pdf

結合度: TDDが悪く見えるけど微妙凝集度: TDDの経験が足らないテストカバレッジ: TDDは非常に良い

TDDの効果の研究をまとめた研究

やっとむ TDD 検索

良い影響より影響なしのほうが多い

TDDは無意味

Jim Coplien (ジム・コプリン)『組織パターン』著者スクラムの成立に影響

https://www.facebook.com/yattom/posts/731467806867197

私がFacebookにTDDのことを書いたらすごい爆撃を食らった

TDDは悪い設計を生む

そういう研究論文が多数ある

TDDより優れたやり方がある

人にTDD勧めるとかお前ふざけんな

DHH(デイヴィッド・ハイネマイヤー・ハンソン)

Rubyist, Ruby on Railsを作った人Basecamp (37signals)

http://david.heinemeierhansson.com/

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.htmlhttp://d.hatena.ne.jp/yach/20140424

TDDは死んだテスティングよ栄えよ

きょんさん （うさ耳）テストアーキテクト

マサカリが痛い なごや方面

http://www.slideshare.net/KyonMm/in-tech-talk

TDDの自殺

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やアジャイルの人は

テストや品質保証の知識が足らない

https://www.flickr.com/photos/iancarroll/4149865894/

Hey It’s not my TDD!

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通りに使われている(少なくとも)テストファースト テスト重視 設計手法 開発(+設計も)

人によって違う意味になっている

What is TDD?Make sure the code works

Always have a goal

Continuous care of cleanness

TDDとは動くコード身近なゴールきれいに保つ

What is TDD, fundamentally?Feedback if the code works

Feedback from user’s viewpoint

Continuous feedback of what is clean

そもそもTDDとは動くかどうかのフィードバックユーザ視点からのフィードバック何がきれいかのフィードバック

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は学びのポイントを作る

Learning ≠ Guarantee of SuccessPlanning for learning is important

Many things are hard to learn by TDD

There are cases TDD is not effective / feasible

学ぶだけでは成功しない何をどうやって学ぶか、計画せよ

TDDだけでは足らない

You need a lot for clean code

TDD is just another toolNot a silver bullet

Can go awryYet some people do well with TDD

TDDは道具にすぎない銀の弾丸ではない

TDDのせいでダメになることも

Kentは最近のFacebookのハッカソンで、半分程度はTDDが適用できたが、残りの半分ではTDDは不適切だったと話しました。TDDが適用可能なコードでは楽しく作業できたものの、そうでないパートはやりにくかったそうです。

(中略)

Davidの場合は、TDDがうまくいく状況を経験したことはあるものの、彼の仕事のほとんどのケースではうまくいかないと言います。そんな彼の疑問は、TDDを機能させることに伴う犠牲は何かということです。多くのプログラマが下手なトレードオフをしています。

http://martinfowler.com/articles/is-tdd-dead/http://postd.cc/is-tdd-dead-part1/

TDDの効果の研究をまとめた研究

やっとむ TDD 検索

影響なしが多いなかでよい結果を出しているチームもある

TDDは使える

Practice requiredYou must learn and practice to be effective“intensively trained for 3 weeks before project C starts” (Tomazˇ Dogsˇa and David Baticˇ, 2013)

素振り重要

Try and see BY YOURSELVES

自分で試して判断せよ

この話を聞いて、私(Martin)はこれがTDD（あるいは何らかの技術）を、身を持って知る理想的な姿だと言いました。まずは試してみて、とことん使った上で、自分にとってちょうどいい加減を見つける。

(中略)

Kentは、(略)プログラマは、どうしても同じことを何度も何度も繰り返し、物事を複雑にしてもなお、進行中の機能不全のシステムに固執しすぎるきらいがあります。Kentは、リブートして原則に戻ることに大賛成です。

http://martinfowler.com/articles/is-tdd-dead/http://postd.cc/is-tdd-dead-part-2/

My experienceI do TDD these days, but not 100%

I do test first rather sparinglyI confess I don’t write code much anyway …

I know when I should do TDD and not

今でもTDDするが100％ではない(実のところあまりコード書いてない)

TDDをいつ使うか 直感が働く

My experienceTDD 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 doIn this phase, anything you write are

throwaway code

TDD works after you have clear goals

何を作るか見当も付かないとTDDは非効率まず全体像(ハック/アーキテクチャ/事前設計)

目的がはっきりしていればTDDは有効

My experienceAPI, 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

複雑なアルゴリズム→ちゃんと設計

My experienceWith 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もちゃんと使える

My experienceAnything 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使うこともあるよ

Architecture

アーキテクチャという観点

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開催

継続可能なアーキテクチャ

Copyright 2014 Joseph W. Yoder & The Refactory, Inc.

Joseph W. Yoder -- www.refactory.com https://www.slideshare.net/yattom/ss-39226174

Sustaining Your Architecture

大きな泥のカタマリ別名: Shantytown(=写真のスラム街のような都市構造), スパゲッティコード

「大きな泥のカタマリ」は構造が行き当たりばったりで、とりとめのない、いいかげんな、ガムテープと針金でつないだ、スパゲッティコードのジャングルのこと標準的ソフトウェアアーキテクチャでもある。なんでやりたいこととやってることにこんなに差があるのか？

誰もが高品質なソフトを作りたいのに、なんで世の中BBoMだらけなのか？

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい？

汚い部分を局所化するには？

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もある。トレードオフもある。コスト、時間、もしかしたらテクノロジーも。

リファクタリングから良いデザイン (パターン)へ…

Sustaining Your Architecture

“～性” 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「～性」で表現され、非機能要求とも呼ばれる……

いっぽう、機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか？)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョン、ロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し、実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

You need a lot to learn quality

Don’t Do:Become religious nor naysayer

Mandate TDD

Believe everything you hearNumbers don’t lie, people do

TDDの信仰も拒絶も良くないTDD必須とか止めよう

言われたことを盲目的に信じない

TDDの効果の研究をまとめた研究

やっとむ TDD 検索

欠陥は減少 生産性は低下品質は結論できず

それがどうした！

http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

ユニットテストはムダだ(ほとんど)

Do:Find out your impediments

Try TDD for solving an impedimentWith enough training and practice

Evaluate and make it better

Continue

まず障害物を見つける解消のためTDDを試す(練習も忘れずに)

結果を評価して改善するそれを繰り返す

おしまい