BDD,RSpec,翻訳A NEW LOOK AT TEST-DRIVEN DEVELOPMENについて
縁:
最近BDDの开発の実践を応用することを始めて、ちょうど始まって私は多くの人と同じに、北が探し出せないで、使うことができなくて、无数の地方でこのBDDのを绍介することを见ます
pdfドキュメント、BDDの背後にある基礎知識を学び、理解するついでに、私は怠け者です...わからない...ひっくり返しにくい...私はすべて訳さないで、“specification”という言叶、私自身の理解によって“规范”に訳して少し言叶が达しないで、私は更に訳さない倾向があって、要するに彼が何なのかを理解することができる限り、私は彼が何を訳すべきか気にしません.
[size=large;]
A NEW LOOK AT TEST-DRIVEN DEVELOPMENT[/size]
Dave Astels
[email protected]
The Problem
現在、テスト駆動開発(TDD)は日中天のように、多くの大手企業がプログラマーにTDDの方法を学ぶために巨額を費やしている.TDDもイベントパーティーの話題...「敏捷」や他の話題のように.TDDに関する専門書がたくさんあります.中にはJolt大賞まで受賞した人もいる.だからすべてがいいように見えます.誰もがTDDを理解し、TDDから大きなメリットを得ましたよね?
Fat Chance!
私が接触している多くの人の中で本当にTDDを知っている人は多くありません.これは多くの人が実際にTDDから何のメリットを得ていないことを意味し、何か問題が発生していますか?
The focus on testing
よし...まず人々はいつもテストは大したことではないと思っています.
確かに、差は多くありません.and you end up with a nice low level regression suite...しかし、この過程は良い体験を生むことはありません.だからどうして体験をもっとよくしないのですか?どうしてみんながプロセス体験をもっとよくすることができなかったのですか?歴史から始めましょう.数年前、私はCoad Letterのために文章を書いた.本文ではTDDの背景知識(Ron Jeffriesのどこから得たのか):
「XPの基本原則は、breakの可能性のあるすべての状況をテストすることです.現在、いずれにしても、XPのテスト実践者はテスト駆動開発に進出しています」
その时に戻って、彼らはテストを书くことを讨论して、テストという言叶は彼らの中心语になって、だから人々はやっとこのようにテストという言叶を理解します!彼らがTestCasesやTestSuites、Testsと言ったとき、彼らは実は他のことを言っていたわけではありませんでした.すべてではないが、ほとんどのxUnitテストフレームワークはテスト方法にtest名を付けることを要求している.新しいバージョンのJUnit(バージョン4)は、命名規則に依存しないか、テストにTestCaseを継承させるが、これらのキーワードはいずれもannotationでテストのキーワードとして保持または使用される.
実際にはTDDが進化した後、私たちが見たのはもう全く違うものです.もとの基础の上で改正するのではありませんて、もとのXP実践者达はテストを书いてすべてのbreakのものをテストして、彼らが先にテストを书いて、更に1つの小さいテストで私达の新しい机能を说明して、それからコードして、それから次の小さいテストを书きます...周而复始.,,TDDは私たちが追求している最終目標ではありません...ただ過程のマイルストーン
Units
もちろん、「unit」という言葉は矛盾の焦点となっている.まずこれはあいまいな言葉で、第2に彼はコードを構造から分割することを暗示している(例えば、独立したmethodやclassをテストすべきだと考えられている).私たちは「unit」をこのように理解すべきではありません.私たちは彼を行為の断面と理解すべきだ.
「unit testing」がコードの構造に従ってテストテストを分割し、手配するように導いたことを想像してみてください.例えばクラスのファイルごとに対応する
これは私たちが望んでいるものではありません...我々は行動から切り離したい...我々は典型的な「ユニットテスト」よりも細粒度の面でテストを展開することを望んでいる.私が前に言ったTDDのように、私たちはもっと小さく、分割できる行為に集中しなければなりません.1つのメソッドの1つの小さな断面、例えば「リストが空の場合、オブジェクトのadd()メソッドを呼び出し、リストには1つのものしかないはずだ」.メソッドは様々なコンテキストで呼び出され、通常はこの明確なパラメータに伴って明確な結果を返すことができます.「テストごとに断言を書く」というblogを書きたいほどです.
だから、これはちょうど必要です.手紙が届かないいい考えだ...彼をパッケージにカプセル化し、テストに対する人々の見方を変えた.
The Result
どうしてこの問題がありますか.人々が通常どのようにテストを考えているかを考えてみましょう.
プログラマーは「すべてのテストを書くつもりはありません」「これは簡単なコードです.テストする必要はありません」「テストは時間の無駄です」「私はもう何度もやっています(ループ/データ取得/機能など)」とよく考えています.
プロジェクトマネージャは、「コードが完了したらテストします」、「テスト担当者がいます」、または「現在、この上で時間を無駄にすることはできません」とよく考えています.
だから、多くのテストの見方に従って、テストの欠点と私たちがテストをしない理由を簡単に得ることができます.特に時間がすでにプロジェクトの圧力の下で
So if it's not about testing, what's it about
これはあなたが半分になる前に何をするかを考えている問題を解決します.あなたは次の需要を書いて、1つの小さい行為の切面に対して、はっきりしていて、岐義がなくて、実行可能な形式で説明します.これは難しくない.これはテストを書いていますか?いいえ、これはコードを書くのに何をする必要があるかを意味します.これは、コードを書く前にコードの動作を定義することを意味します.しかもあまり時間を費やす必要はない.実際にはコードを書く前にこのステップをするのが一番いいです.この時、あなたはこのことをうまくやるのに十分な情報を持っているからです.TDDのベストプラクティスに似ていて、小さなステップで前進します...一度に小さな行為の接面を定義し、それを実現する.
テストを書くのではなく、行動を書いていることに気づくと君の考えはもう昇華した.クラスごとにテストを作成したり、方法ごとにテストを作成したりするのがおかしくなります.
Sapir-Whorf Hypothesis
Wikipediaから抜粋した背景知識:
(略、pdf原文、または
ここブラウズ)
私の目的はあなたが使っている言語があなたの考えに影響を与えたことを証明することです...もしあなたの考えを変えたいなら、この点を理解することはあなたの言語を変えるのに役立ちます.
So what to do?
まず「テスト」という用語を考えるのをやめ、Bob Martinは何年も前から「Specification,not Verification」と言っていた.Bobの意味はverification(よく知られている「テスト」)は、あなたのコードの機能が正しいことを確認することです.specificationがあなたのコードを定義する場合、どのような機能があるべきかを意味します.
いくつかのxUnitツールを使用して、彼は「テスト」を中心とした言語なので、このことを困難にしました.新しいフレームワークが必要ですThoughtWorksのDan NorthはjBehaveというプロジェクトに着手してこの問題を解決しています.私と他の人はRubyの行為specifyingフレームワークrSpecのためにコードを提出しました.もっとrSpecの詳細をお見せします.
A Behaviour Specification Framework
動作specificationはどのように見えますか?最初は昔のxUnitに似ていますは で動作可能誰もが彼をよく知っている 一つの最も主要な違いはキーワードの使用である.従来のやり方を継承Contextで置き換えてTestCaseを継承する.メソッド名の接頭辞'test'を'should'で置き換えると、ネーミングモードに悩まされる必要がなくなり、より適切な名前を選択して、チェック用の断言(assertEquals(expected,actual))に置き換えることができます.specifyはShouldBeEqual(actual,expected)のようなアイテムを提出します.
SmalltalkとRubyでは、クラスライブラリにテストフレームワークを埋め込む方法がより自然に見えます(ちなみにSmalltalkの一般的な方法です)、次のような例を書くべきです.
(略...pdfの元のドキュメントを見てください.JEのエディタで表を編集することはできません)
What Now?
前述したように、Dan NorthのjBehaveプロジェクトは、動作specificationのためのjUnit代替案を作成し、ダウンロードして体験することができます.
ルビーを使えばrSpecのフレームワークを手に入れて使い始めることができます現在rSpecでは、任意のオブジェクトを呼び出すための次の方法が提供されています.注意してください...任意のオブジェクト:
(略...pdfで述べたこれらの使い方はもう時代遅れだと気づきました...新しいバージョンはもっと簡単で明確な方法で使われています)
すべての式は、パラメータ情報などのオプションです.xUnitと同様にsetupとteardownはoverriding.彼らは同じ方法で同じことをした.
行動specificationは何に見えますか?はい、ここは私のTDDの本の例のrSpec版です.
Guidelines
何が一番気になるのか、それを使ってContext classesと名付けます.例えば、EmptyMovieListやMovieListなどです.彼らはspecificationメソッドだけを含んでコンテキストに直接関連している.
あなたが注目しているspecificationの名前で例を挙げます
should_have_size_of_0
Context classと式の方法はすべて読みやすくて、そして正確にあなたに何が発生することを教えるべきです:EmptyMovieList.should_have_size_of_0.
どんなに簡単にspecificationの内容を表現したか考えてみましょう
あなたのspecificationの方法はできるだけ簡単で、短くて、あなたが作っているものに注目しなければなりません.式...素晴らしい...彼はあなたが求めている聖杯のはずです.単純は美/小、単純、集約的、理解しやすいクラスと方法が大きい、冗長、複雑なクラスまたは方法より優れている.
Summary TDDを使うのが一番の問題は彼が私に異なる方向を歩くことに影響を与える傾向があることです...誤った方向 検証テスト ではなく、行動specificationsを考える必要があります. specificationsの価値は、各動作、より少ない依存クラステスト、またはメソッドテストを考慮し、最終的に実行可能な良いドキュメント を得ることです. TDDでは、誰も名前の意味を変えません(私たちが望んでいるわけではありません)、私たちは新しい名前で新しい仕事の方法を命名する必要があります.Dan Northは私たちにBD:Behavior Driven Developmentをくれました. Acknowledgements
スティーブン・ベーカーに感謝し、Gabriel BaumanとAslak Hellessoyはこの文章の第1版を討論し、rubyの枠組みを書き始め、この考えを現実にした.Kay Pentecost、彼のfeedbackの良いアイデアtest-avoidanceはすでにこの文章の下書き版に含まれています.
最近BDDの开発の実践を応用することを始めて、ちょうど始まって私は多くの人と同じに、北が探し出せないで、使うことができなくて、无数の地方でこのBDDのを绍介することを见ます
pdfドキュメント、BDDの背後にある基礎知識を学び、理解するついでに、私は怠け者です...わからない...ひっくり返しにくい...私はすべて訳さないで、“specification”という言叶、私自身の理解によって“规范”に訳して少し言叶が达しないで、私は更に訳さない倾向があって、要するに彼が何なのかを理解することができる限り、私は彼が何を訳すべきか気にしません.
[size=large;]
A NEW LOOK AT TEST-DRIVEN DEVELOPMENT[/size]
Dave Astels
[email protected]
The Problem
現在、テスト駆動開発(TDD)は日中天のように、多くの大手企業がプログラマーにTDDの方法を学ぶために巨額を費やしている.TDDもイベントパーティーの話題...「敏捷」や他の話題のように.TDDに関する専門書がたくさんあります.中にはJolt大賞まで受賞した人もいる.だからすべてがいいように見えます.誰もがTDDを理解し、TDDから大きなメリットを得ましたよね?
Fat Chance!
私が接触している多くの人の中で本当にTDDを知っている人は多くありません.これは多くの人が実際にTDDから何のメリットを得ていないことを意味し、何か問題が発生していますか?
The focus on testing
よし...まず人々はいつもテストは大したことではないと思っています.
確かに、差は多くありません.and you end up with a nice low level regression suite...しかし、この過程は良い体験を生むことはありません.だからどうして体験をもっとよくしないのですか?どうしてみんながプロセス体験をもっとよくすることができなかったのですか?歴史から始めましょう.数年前、私はCoad Letterのために文章を書いた.本文ではTDDの背景知識(Ron Jeffriesのどこから得たのか):
「XPの基本原則は、breakの可能性のあるすべての状況をテストすることです.現在、いずれにしても、XPのテスト実践者はテスト駆動開発に進出しています」
その时に戻って、彼らはテストを书くことを讨论して、テストという言叶は彼らの中心语になって、だから人々はやっとこのようにテストという言叶を理解します!彼らがTestCasesやTestSuites、Testsと言ったとき、彼らは実は他のことを言っていたわけではありませんでした.すべてではないが、ほとんどのxUnitテストフレームワークはテスト方法にtest名を付けることを要求している.新しいバージョンのJUnit(バージョン4)は、命名規則に依存しないか、テストにTestCaseを継承させるが、これらのキーワードはいずれもannotationでテストのキーワードとして保持または使用される.
実際にはTDDが進化した後、私たちが見たのはもう全く違うものです.もとの基础の上で改正するのではありませんて、もとのXP実践者达はテストを书いてすべてのbreakのものをテストして、彼らが先にテストを书いて、更に1つの小さいテストで私达の新しい机能を说明して、それからコードして、それから次の小さいテストを书きます...周而复始.,,TDDは私たちが追求している最終目標ではありません...ただ過程のマイルストーン
Units
もちろん、「unit」という言葉は矛盾の焦点となっている.まずこれはあいまいな言葉で、第2に彼はコードを構造から分割することを暗示している(例えば、独立したmethodやclassをテストすべきだと考えられている).私たちは「unit」をこのように理解すべきではありません.私たちは彼を行為の断面と理解すべきだ.
「unit testing」がコードの構造に従ってテストテストを分割し、手配するように導いたことを想像してみてください.例えばクラスのファイルごとに対応する
これは私たちが望んでいるものではありません...我々は行動から切り離したい...我々は典型的な「ユニットテスト」よりも細粒度の面でテストを展開することを望んでいる.私が前に言ったTDDのように、私たちはもっと小さく、分割できる行為に集中しなければなりません.1つのメソッドの1つの小さな断面、例えば「リストが空の場合、オブジェクトのadd()メソッドを呼び出し、リストには1つのものしかないはずだ」.メソッドは様々なコンテキストで呼び出され、通常はこの明確なパラメータに伴って明確な結果を返すことができます.「テストごとに断言を書く」というblogを書きたいほどです.
だから、これはちょうど必要です.手紙が届かないいい考えだ...彼をパッケージにカプセル化し、テストに対する人々の見方を変えた.
The Result
どうしてこの問題がありますか.人々が通常どのようにテストを考えているかを考えてみましょう.
プログラマーは「すべてのテストを書くつもりはありません」「これは簡単なコードです.テストする必要はありません」「テストは時間の無駄です」「私はもう何度もやっています(ループ/データ取得/機能など)」とよく考えています.
プロジェクトマネージャは、「コードが完了したらテストします」、「テスト担当者がいます」、または「現在、この上で時間を無駄にすることはできません」とよく考えています.
だから、多くのテストの見方に従って、テストの欠点と私たちがテストをしない理由を簡単に得ることができます.特に時間がすでにプロジェクトの圧力の下で
So if it's not about testing, what's it about
これはあなたが半分になる前に何をするかを考えている問題を解決します.あなたは次の需要を書いて、1つの小さい行為の切面に対して、はっきりしていて、岐義がなくて、実行可能な形式で説明します.これは難しくない.これはテストを書いていますか?いいえ、これはコードを書くのに何をする必要があるかを意味します.これは、コードを書く前にコードの動作を定義することを意味します.しかもあまり時間を費やす必要はない.実際にはコードを書く前にこのステップをするのが一番いいです.この時、あなたはこのことをうまくやるのに十分な情報を持っているからです.TDDのベストプラクティスに似ていて、小さなステップで前進します...一度に小さな行為の接面を定義し、それを実現する.
テストを書くのではなく、行動を書いていることに気づくと君の考えはもう昇華した.クラスごとにテストを作成したり、方法ごとにテストを作成したりするのがおかしくなります.
Sapir-Whorf Hypothesis
Wikipediaから抜粋した背景知識:
(略、pdf原文、または
ここブラウズ)
私の目的はあなたが使っている言語があなたの考えに影響を与えたことを証明することです...もしあなたの考えを変えたいなら、この点を理解することはあなたの言語を変えるのに役立ちます.
So what to do?
まず「テスト」という用語を考えるのをやめ、Bob Martinは何年も前から「Specification,not Verification」と言っていた.Bobの意味はverification(よく知られている「テスト」)は、あなたのコードの機能が正しいことを確認することです.specificationがあなたのコードを定義する場合、どのような機能があるべきかを意味します.
いくつかのxUnitツールを使用して、彼は「テスト」を中心とした言語なので、このことを困難にしました.新しいフレームワークが必要ですThoughtWorksのDan NorthはjBehaveというプロジェクトに着手してこの問題を解決しています.私と他の人はRubyの行為specifyingフレームワークrSpecのためにコードを提出しました.もっとrSpecの詳細をお見せします.
A Behaviour Specification Framework
動作specificationはどのように見えますか?最初は昔のxUnitに似ています
SmalltalkとRubyでは、クラスライブラリにテストフレームワークを埋め込む方法がより自然に見えます(ちなみにSmalltalkの一般的な方法です)、次のような例を書くべきです.
(略...pdfの元のドキュメントを見てください.JEのエディタで表を編集することはできません)
What Now?
前述したように、Dan NorthのjBehaveプロジェクトは、動作specificationのためのjUnit代替案を作成し、ダウンロードして体験することができます.
ルビーを使えばrSpecのフレームワークを手に入れて使い始めることができます現在rSpecでは、任意のオブジェクトを呼び出すための次の方法が提供されています.注意してください...任意のオブジェクト:
(略...pdfで述べたこれらの使い方はもう時代遅れだと気づきました...新しいバージョンはもっと簡単で明確な方法で使われています)
すべての式は、パラメータ情報などのオプションです.xUnitと同様にsetupとteardownはoverriding.彼らは同じ方法で同じことをした.
行動specificationは何に見えますか?はい、ここは私のTDDの本の例のrSpec版です.
require 'spec'
require 'movie'
require 'movie_list'
class EmptyMovieList < Spec::Context
def setup
@list = MovieList.new
end
def should_have_size_of_0
@list.size.should_equal 0
end
def should_not_include_star_wars
@list.should_not_include "Star Wars"
end
end
class OneMovieList < Spec::Context
def setup
@list = MovieList.new
star_wars = Movie.new "Star Wars"
@list.add star_wars
end
def should_have_size_of_1
@list.size.should_equal 1
end
def should_include_star_wars
@list.should_include "Star Wars"
end
end
Guidelines
何が一番気になるのか、それを使ってContext classesと名付けます.例えば、EmptyMovieListやMovieListなどです.彼らはspecificationメソッドだけを含んでコンテキストに直接関連している.
あなたが注目しているspecificationの名前で例を挙げます
should_have_size_of_0
Context classと式の方法はすべて読みやすくて、そして正確にあなたに何が発生することを教えるべきです:EmptyMovieList.should_have_size_of_0.
どんなに簡単にspecificationの内容を表現したか考えてみましょう
あなたのspecificationの方法はできるだけ簡単で、短くて、あなたが作っているものに注目しなければなりません.式...素晴らしい...彼はあなたが求めている聖杯のはずです.単純は美/小、単純、集約的、理解しやすいクラスと方法が大きい、冗長、複雑なクラスまたは方法より優れている.
Summary
スティーブン・ベーカーに感謝し、Gabriel BaumanとAslak Hellessoyはこの文章の第1版を討論し、rubyの枠組みを書き始め、この考えを現実にした.Kay Pentecost、彼のfeedbackの良いアイデアtest-avoidanceはすでにこの文章の下書き版に含まれています.