tdd #nagoyatesting

うさぎ組 in

Nagoya.Testing2012.02.26

Self Introduction名前：きょん(kyon_mm)

Blog : うさぎ組

Target : 開発環境改善

Groovy、テスト、自動化、アジャイル、品質保証

24歳うさみみ系男子

SCMBootCamp、Nagoya.Testing主宰

今日のテーマ

TDD概論

以降は個人の解釈に基づくものであり公式見(ry

TDD概論TDDとは？

TDDはテストなのか？

TDDの種類は？

TDDの特性は？

TDDのスキル

まとめ

TDDはドッグフーディングにより不安を解消する

TDDのライフサイクル


画像引用元 http://d.hatena.ne.jp/shuji_w6e/20110429/1304079615

http://d.hatena.ne.jp/shuji_w6e/20110429/1304079615




TODOリスト





RED -> GREEN -> REFACTORING ->

TODOリスト





RED -> GREEN -> REFACTORING ->

テストリスト

個人的に重要なのはテストリスト

REFACTORING





TDDの種類は？

TDDの特性は？

TDDのスキル

まとめ

TDDはテストをしているわけじゃない

プロダクトに自信をもつための行為がTDDであり、現状では単体テスト以降の自動テストにも流用できている。

現状の結果として単体テストの代替物と勘違いさ

れることがある

Developer TestCustomer Test

QA Test


QA Test

TDD

結合テストなど

非機能

TDD


QA Test

TDD

結合テストなど

非機能

TDDこれはテストじゃない

でも、

品質保証の自動テストに流用できるようにする方向でいくなら、TDDは

Test Architecture として捉えられるのでテストになると思う。



TDDの種類は？

TDDの特性は？

TDDのスキル

まとめ

TDDの種類

TDD

BDD

STDD

SATDD

UATDD

VOTDD

TDDの種類

TDD

BDD

STDD

SATDD

UATDD

VOTDD

STDD, SATDD, UATDD, VOTDDはTDDの何かを明確にしたり、付加したもの

TDDとBDDは表現方法の違い

TDD(=テスト)

開発者の不安を対象にテストコードを書く

いわゆる原義のTDD

この頃はxUnit系と言われているテストフレームワークが主流

だった

BDD(=振る舞い)

基本的にはTDDと一緒(表現方法が異なるのみ)

決定的に違うのは自然言語指向で書くということ

目的は顧客やPOに書いてもらえるテストコード

これを実現するためにSpec系のテストフレームワークが発生

Webアプリ化したのがFitNesse

STDD(=ストーリーテスト)

ユースケースやユーザーシナリオをテストコードにする

Spec系フレームワークで書かれる事が多い

BDDではSTDDとTDDがあると言われる事が多いが、BDDは

表現方法が異なるだけなので、TDDが他のTDDになりえるよ

うにBDDも他のTDDになりえる。

SATDD(=ストーリー受け入れテスト)

スクラムなどをはじめとするアジャイルでのストーリーに対

する受け入れテストをテストコードにする

個人的にはストーリーって言うよりフィーチャーの方が似

合っていると思うというか、随分とプロセス依存な名前だ

なぁと思ったり。

UATDD(=ユーザー受け入れテスト)

ユーザーの受け入れ基準をテストコードにする

ATDDの初出はUATDDの意味合いで出てきたけど、STDDが

派生して、アジャイルの文脈でSATDDが出現してきたように

見える。

VOTDD(=検証指向テスト)

TDDに検証指向のテストを組み込んだプロセス

目標はTDDに検証を持ち込む点なので、従来のソフトウェア

テストのあらゆるフェーズや技法が投入可能だと思われる

例）AllPair法、原因結果グラフ、HAYST法、ゆもつよメソッ

ド



TDDの種類は？

TDDの特性は？

TDDのスキル

まとめ

TDDの特性

テストコードを書くタイミング

リファクタリングをするタイミング

網羅基準

対象範囲

モックやスタブの範囲

テストコードを書くタイミング

TestFirst

プロダクトコード変更前に必ず失敗するテストコードを書く

変更箇所対象切り替え毎

次の変更箇所に移るまでには現在実装している箇所のテストコードを

書く

対象機能実装完了時

現在取り組んでいる機能が実装できてからテストコードを書く

リファクタリングをするタイミング

Greenになったら

テストコードが通るたびにリファクタリングの機会を伺う

変更箇所対象切り替え毎

次の変更箇所に移るまでには現在実装している箇所のリファクタリングを

する

対象機能実装完了時

現在取り組んでいる機能が実装できてからリファクタリングをする

網羅基準

三角測量、境界値分析、原因結果グラフ、状態遷移な

ど、どの程度まで厳密にテストコードに表現するか

対象範囲

テストコードを書く対象をどこまで広げるかモデル、

GUI、DB、通信処理など

モックやスタブの範囲

どこまでをプロダクトコード以外のモックやスタブと

するかパッケージレベルでの境界、ネットワークレベ

ルでの境界など



TDDの種類は？

TDDの特性は？

TDDのスキル

まとめ

TDDのスキル成長=TDDしなくなること



TDDの種類は？

TDDの特性は？

TDDのスキル

まとめ

TDD概論まとめ

TDDはテストではない

いろんな種類があるけど、自分で認識してカテゴライズでき

ればそれでいい

原則や行為のレベルを自分で最適化することが大切

最後にはTDDしなくてもいいようになろう

ご清聴ありがとうぴょん◆

tdd #nagoyatesting

Technology