atdd's Wiki - Use a Proper Format Diff
- Added parts are displayed like this.
- Deleted parts are displayed
like this.
* (Exampleを記述する上で)適切な記述というのはチーム、プロジェクト、組織による。
* まず、誰がテストを読むか。プログラマー、プロダクトオーナー、顧客。
* テストのメンテナーのことも要考慮。
* 今日書いたフィーチャーに対する、見取り図をほしい。
* traditionalなspecifaction.
* ATDD friendlyなテスト自動化フレームワークは、テストデータとテストを自動化するコードを分けて記述する。
* test autonation code はテストコードの開発と、アプリケーションの開発の間をのり付けする(glue)。
* アプリケーションが必要とするexampleを記述するのはいくつかのほうほうがある。
# BDDのフォーマットはGiven-When-Thenの語彙からなり、特定のfeatureのexpectationを構造化する手助けになる。
# tableted formats
# keyword(data)駆動テスト
!! BDD
* BDDは、まずDan Northによって記された。
* Given-When-Then
* Given partでは、全ての事前条件を書く。
* When partでは、トリガーとなる操作と全てのパラメーターを書く。
* Then partでは、When partの後の全ての事後条件を書く。
* BDDのマントラの一つに、outside-in で開発するというのがある。
* BDDは、customerからの要件からコードの開発を進めていくのを好む。
* ～
!! Tabulated Formats
* テーブル構造で要件を表現する。
!! Decision Table
* parking durationが入力値となり、駐車料金が出力値となる。
* 複数の値をセットアップする例(Listing 9.3)
* システムから集める必要がある場合には、Query tablesを使う(Listing 9.4)
!! Script Tables
* ワークフローを記述する必要がある場合は、Script Tablesを使うことができる(Listing 9.5)
* Script Tablesは、FITでは ActionFixtureと呼ばれる。FitLibraryでは、DoFixture。
* 大抵のケースでは、あらゆるものをテーブルに記述することができる。
* Script Tablesでは、広範囲の操作を記述する必要がある場合に向いている。
!!Keyword-Driven Automation
* 操作のまとまりを、キーワードとして表現することができる。
* キーワードのつらなりで、上位レベルの操作を表現する。
* 交通信号での、不正な組み合わせのシナリオの例。(Listing 9.6)
* キーワードを使用すると、テストデータとtest autonation code の間を流れるように表現することができる。
* ～
! Glue Code and Support Code
* exampleをどう自動化するかは、使用するフレームワークに強く依存する。
* Javaのフレームワークでは、givenの記述に対応して実行するコードをみつけるために、Javaのアノテーションを使用する。他のフレームワークでは、functionの名前をcamel caseにしたものを使う。
* フレームワークやツールに無頓着だと、glue codeをどう書くかと言うことに注意する必要がある。
* glue codeやsupport codeを書きながら開発することになることには、気を留めていないようだ。(?)
* アプリケーションとテストの間がすんなりつながっていると、(プロダクション)コードはシンプルになり、メンテナンスしやすくなる。
* glue codeとsupport codeのデザインの原則に、producition codeと同じくらいの注意を払っていないと、コードベースはメンテナンスしにくくなる。
* シンプルなコードベースからはじめましょう。
* 自動化された受入テストを書くことから始められたらいいなあ。
* あるクライアントでは、2名×2時間で、自動化された受入テストを作れるようになった。
* ～
* 機能が増えていくにつれ、自分は既存のコードから積極的にコンポーネントを抽出するようにしている。
* partⅡでの LightStateEditorでTDDしながらコンポーネントを加えたように。
* 実際の所、テストをテストしている。
* ある企業では、automation codeの静的解析とカバレッジ測定を行い、produciton codeとautomation codeのメトリクスを比較していた。
* 極端な例だと思うなら、2009年に私が聞いた話をしよう。
* チームに外部からテスト自動化の設計者が訪れた。
* 設計者はsupport codeのロジックが複雑で、追加がしずらいと感じた。
* そこで、彼は複雑なコードに対しては、TDDで追加していった。
* 彼がさった後、アプリケーションのカバレッジは10%から15%上昇した。
* test automation codeを開発することは、ソフトウェア開発そのものである。
* それゆえ、glue codeやsupport codeには、producition codeを開発するのと同じ原則を適用すべきだ。
* test automation codeにデザインが欠けていたために、バグのあるもろくなったテストを見てきた。
* TDDはドキュメント化を提供し、理解の助けとなる。
* glue codeとsupport codeにユニットテストを加えることの必要性は、partⅡでATDDの手法をつかったなら、より明らかになった。(?)
* 受入テストが機能していることによって、アプリケーションのドメインを見つけることができる。
* ～
* glue codeへのユニットテストが無い場合は、まずユニットテストを加えることによって、新しいドメインをTDDで開発することができる。
! The Right Format
* ただしいフォーマットについて。
* ここではBDD/tabulated format/keyword-based examples を紹介した。
* 以前から、大半のツールはいずれかのフォーマットを使うことが出来る。
* Fitness SLiM frameworkではtabulated formatとdecsion and query tableを使うことができる.
* SLiMで、script tableを使って、Given-When-Thenのフォーマットを使うこともできる。
* Robot Frameworkも同様。
* 適切なフォーマットで、exampleを自然なスタイルで記述することに注力できるのは素晴らしいことだ。～
* 多くのチームは特定のツールで実装することから始めるが、～...?
* あなたがテストを書く時を例に取ると、exampleを自動化するにあたっては、利害関係者が複数存在する。
* exampleを理解して、descriptionを記述するプログラマー。
* exampleを自動化するプログラマー。
* customerとプロダクトオーナー。
* 将来的にシステムを保守する人。
* 全ての利害関係者がexampleとテストをすばやく理解することができるべきだ。
* そのためには、テストをよんで、コンテキストと、(テストが)何にフォーカスしているかを読み取れければいけない。
* テストを読んで理解するのに時間がかかるほど、考察に使う時間が費やされていく。
* すなわち、生産的な仕事に使う時間が減っていく。
* 生産的な仕事が減るほど、抑圧的に感じるようになる。
* 抑圧的に感じると、テストを手抜きするようになり、手抜きするほど、テストは理解不能になり、落下のスパイラルに陥る。(Figure 9.1)
* この悪循環を打ち破ることができる。
* ～
* チームは、受入テストをコミュニケーションのデバイスとして使う。
* ～
* アプリケーションが開発されれている間は、メンバー間での伝達に(使われる)
* 成功しているチームは、テストの可読性を保ち、齟齬を減らすように努める。
* 2009年にEnrique Comba-Riepenhausenから聞いたところでは、オンサイト顧客は受入テストだけでなく、ユニットテストやドメインのコードも読み取ることができた。彼のチームは、Eric Evansが言うところのユビキタス言語のコンセプトを実現していた。
* 全てのプロジェクトはユビキタス言語としての共通の語彙を共有する。
* プロジェクトの中で語彙の通訳が必要になるほど、行き違いの可能性が高まる。
* ビジネスのドメインが受入テストの中で同じ用語で表現されていると、顧客がテストを確実に理解出来る。
* ドメインのコードを共通の言語でモデリングできれば、誰もが後になってからの行き違いなしに、共通の理解に到達することができる。
* まず、誰がテストを読むか。プログラマー、プロダクトオーナー、顧客。
* テストのメンテナーのことも要考慮。
* 今日書いたフィーチャーに対する、見取り図をほしい。
* traditionalなspecifaction.
* ATDD friendlyなテスト自動化フレームワークは、テストデータとテストを自動化するコードを分けて記述する。
* test autonation code はテストコードの開発と、アプリケーションの開発の間をのり付けする(glue)。
* アプリケーションが必要とするexampleを記述するのはいくつかのほうほうがある。
# BDDのフォーマットはGiven-When-Thenの語彙からなり、特定のfeatureのexpectationを構造化する手助けになる。
# tableted formats
# keyword(data)駆動テスト
!! BDD
* BDDは、まずDan Northによって記された。
* Given-When-Then
* Given partでは、全ての事前条件を書く。
* When partでは、トリガーとなる操作と全てのパラメーターを書く。
* Then partでは、When partの後の全ての事後条件を書く。
* BDDのマントラの一つに、outside-in で開発するというのがある。
* BDDは、customerからの要件からコードの開発を進めていくのを好む。
* ～
!! Tabulated Formats
* テーブル構造で要件を表現する。
!! Decision Table
* parking durationが入力値となり、駐車料金が出力値となる。
* 複数の値をセットアップする例(Listing 9.3)
* システムから集める必要がある場合には、Query tablesを使う(Listing 9.4)
!! Script Tables
* ワークフローを記述する必要がある場合は、Script Tablesを使うことができる(Listing 9.5)
* Script Tablesは、FITでは ActionFixtureと呼ばれる。FitLibraryでは、DoFixture。
* 大抵のケースでは、あらゆるものをテーブルに記述することができる。
* Script Tablesでは、広範囲の操作を記述する必要がある場合に向いている。
!!Keyword-Driven Automation
* 操作のまとまりを、キーワードとして表現することができる。
* キーワードのつらなりで、上位レベルの操作を表現する。
* 交通信号での、不正な組み合わせのシナリオの例。(Listing 9.6)
* キーワードを使用すると、テストデータとtest autonation code の間を流れるように表現することができる。
* ～
! Glue Code and Support Code
* exampleをどう自動化するかは、使用するフレームワークに強く依存する。
* Javaのフレームワークでは、givenの記述に対応して実行するコードをみつけるために、Javaのアノテーションを使用する。他のフレームワークでは、functionの名前をcamel caseにしたものを使う。
* フレームワークやツールに無頓着だと、glue codeをどう書くかと言うことに注意する必要がある。
* glue codeやsupport codeを書きながら開発することになることには、気を留めていないようだ。(?)
* アプリケーションとテストの間がすんなりつながっていると、(プロダクション)コードはシンプルになり、メンテナンスしやすくなる。
* glue codeとsupport codeのデザインの原則に、producition codeと同じくらいの注意を払っていないと、コードベースはメンテナンスしにくくなる。
* シンプルなコードベースからはじめましょう。
* 自動化された受入テストを書くことから始められたらいいなあ。
* あるクライアントでは、2名×2時間で、自動化された受入テストを作れるようになった。
* ～
* 機能が増えていくにつれ、自分は既存のコードから積極的にコンポーネントを抽出するようにしている。
* partⅡでの LightStateEditorでTDDしながらコンポーネントを加えたように。
* 実際の所、テストをテストしている。
* ある企業では、automation codeの静的解析とカバレッジ測定を行い、produciton codeとautomation codeのメトリクスを比較していた。
* 極端な例だと思うなら、2009年に私が聞いた話をしよう。
* チームに外部からテスト自動化の設計者が訪れた。
* 設計者はsupport codeのロジックが複雑で、追加がしずらいと感じた。
* そこで、彼は複雑なコードに対しては、TDDで追加していった。
* 彼がさった後、アプリケーションのカバレッジは10%から15%上昇した。
* test automation codeを開発することは、ソフトウェア開発そのものである。
* それゆえ、glue codeやsupport codeには、producition codeを開発するのと同じ原則を適用すべきだ。
* test automation codeにデザインが欠けていたために、バグのあるもろくなったテストを見てきた。
* TDDはドキュメント化を提供し、理解の助けとなる。
* glue codeとsupport codeにユニットテストを加えることの必要性は、partⅡでATDDの手法をつかったなら、より明らかになった。(?)
* 受入テストが機能していることによって、アプリケーションのドメインを見つけることができる。
* ～
* glue codeへのユニットテストが無い場合は、まずユニットテストを加えることによって、新しいドメインをTDDで開発することができる。
! The Right Format
* ただしいフォーマットについて。
* ここではBDD/tabulated format/keyword-based examples を紹介した。
* 以前から、大半のツールはいずれかのフォーマットを使うことが出来る。
* Fitness SLiM frameworkではtabulated formatとdecsion and query tableを使うことができる.
* SLiMで、script tableを使って、Given-When-Thenのフォーマットを使うこともできる。
* Robot Frameworkも同様。
* 適切なフォーマットで、exampleを自然なスタイルで記述することに注力できるのは素晴らしいことだ。～
* 多くのチームは特定のツールで実装することから始めるが、～...?
* あなたがテストを書く時を例に取ると、exampleを自動化するにあたっては、利害関係者が複数存在する。
* exampleを理解して、descriptionを記述するプログラマー。
* exampleを自動化するプログラマー。
* customerとプロダクトオーナー。
* 将来的にシステムを保守する人。
* 全ての利害関係者がexampleとテストをすばやく理解することができるべきだ。
* そのためには、テストをよんで、コンテキストと、(テストが)何にフォーカスしているかを読み取れければいけない。
* テストを読んで理解するのに時間がかかるほど、考察に使う時間が費やされていく。
* すなわち、生産的な仕事に使う時間が減っていく。
* 生産的な仕事が減るほど、抑圧的に感じるようになる。
* 抑圧的に感じると、テストを手抜きするようになり、手抜きするほど、テストは理解不能になり、落下のスパイラルに陥る。(Figure 9.1)
* この悪循環を打ち破ることができる。
* ～
* チームは、受入テストをコミュニケーションのデバイスとして使う。
* ～
* アプリケーションが開発されれている間は、メンバー間での伝達に(使われる)
* 成功しているチームは、テストの可読性を保ち、齟齬を減らすように努める。
* 2009年にEnrique Comba-Riepenhausenから聞いたところでは、オンサイト顧客は受入テストだけでなく、ユニットテストやドメインのコードも読み取ることができた。彼のチームは、Eric Evansが言うところのユビキタス言語のコンセプトを実現していた。
* 全てのプロジェクトはユビキタス言語としての共通の語彙を共有する。
* プロジェクトの中で語彙の通訳が必要になるほど、行き違いの可能性が高まる。
* ビジネスのドメインが受入テストの中で同じ用語で表現されていると、顧客がテストを確実に理解出来る。
* ドメインのコードを共通の言語でモデリングできれば、誰もが後になってからの行き違いなしに、共通の理解に到達することができる。