[翻訳]Behavior-driven Development(BDD)行動駆動開発(二)

5689 ワード
IO
テスト駆動開発は開発者のソフトウェア製品の各部分の運営方式に対する理解を体現し、行為駆動開発は開発者のソフトウェア製品の最終的な表現に対する行為の予想に注目している.

動作駆動開発


TDDはプロセスではなくモデルのようなものです.テストを先に記述し、実装し、可能なコード再構成に伴う一連のステップを説明する.ただし、以下の内容はありません.
  • はどこから開発を始めるべきですか.
  • は何をテストすべきか.
  • は、どのように組織し、名前を付けるべきかをテストします.

    • テストドライバ開発というネーミングも疑問ですが、人は存在しないものをテストすることができますか.Dan Northはこれらの問題を研究し,開発者はテストを書くのではなくソフトウェアの特徴的な行為に注目すべきであることを提案した.
    開発が動作駆動である場合,開発はユーザにとって最も重要な機能の一部から始まるべきである.開発者の帽子を置いて、ユーザーの帽子をかぶって、ユーザーの立場から考えることができる.実際、場合によっては、最も難しい部分もここにあり、ユーザーが最も注目している最も重要な行動特性を知ることができないことが多い.しかし、実践と数回の反復を経て、この過程は最終的に透明で有効になるだろう.
    では、次はどのように行動を表現すべきか、Test::Unitベースのテストは次のようになる可能性があります.
    class UserTest < Test::Unit::TestCase

  def test_name_set

    user = User.new "Audrey"

    assert_equal(user.name, "Audrey")

  end

end

    <!--
    .csharpcode, .csharpcode pre
    {
    font-size: small;
    color: black;
    font-family: consolas, "Courier New", courier, monospace;
    background-color: #ffffff;
    /*white-space: pre;*/
    }
    .csharpcode pre { margin: 0em; }
    .csharpcode .rem { color: #008000; }
    .csharpcode .kwrd { color: #0000ff; }
    .csharpcode .str { color: #006080; }
    .csharpcode .op { color: #0000c0; }
    .csharpcode .preproc { color: #cc6633; }
    .csharpcode .asp { background-color: #ffff00; }
    .csharpcode .html { color: #800000; }
    .csharpcode .attr { color: #ff0000; }
    .csharpcode .alt
    {
    background-color: #f4f4f4;
    width: 100%;
    margin: 0em;
    }
    .csharpcode .lnum { color: #606060; }
    -->
    コードは動作しますが、いくつかの欠陥があります.
  • コードには複数のTestがあり、具体的なニーズで代替する必要があります.
  • 文法は分かりにくいです.
  • このコードがどのような内容をテストするのか分からない.

    • BDDでは、次のような赤い内容の動作が随所に見られるはずです.
    describe User do

  it "lets me assign a name" do

    user = User.new "Paul"

    user.name.should == "Paul"

  end

end

    <!--
    .csharpcode, .csharpcode pre
    {
    font-size: small;
    color: black;
    font-family: consolas, "Courier New", courier, monospace;
    background-color: #ffffff;
    /*white-space: pre;*/
    }
    .csharpcode pre { margin: 0em; }
    .csharpcode .rem { color: #008000; }
    .csharpcode .kwrd { color: #0000ff; }
    .csharpcode .str { color: #006080; }
    .csharpcode .op { color: #0000c0; }
    .csharpcode .preproc { color: #cc6633; }
    .csharpcode .asp { background-color: #ffff00; }
    .csharpcode .html { color: #800000; }
    .csharpcode .attr { color: #ff0000; }
    .csharpcode .alt
    {
    background-color: #f4f4f4;
    width: 100%;
    margin: 0em;
    }
    .csharpcode .lnum { color: #606060; }
    -->
    このテストコードの価値は、次のとおりです.
  • 注目点:具体的な動作に対してテストと符号化を行う.
  • ドキュメント:以上の文を読むことで、あなたの同僚は行為の内容を直接理解することができ、コードを読む必要もありません.
  • 回帰:その後、すべての特性を実行すると、回帰テストになります.もし問題が発生したら、すぐにその行為の間違いを見ることができます.

    • テスト構文はソフトウェアの機能動作特性を説明しているが、ユーザーの意図を示すためにいくつかの作業が必要である.Dan Northは、テンプレートを定義して自然言語でこれらの特性を記述することができると考えています.
    Story: Returns go to stock

In order to keep track of stock

As a store owner I want to add items back to stock when they're returned



Scenario 1: Refunded items should be returned to stock

Given a customer previously bought a black sweater from me

And I currently have three black sweaters left in stock

When he returns the sweater for a refund

Then I should have four black sweaters in stock



Scenario 2: Replaced items should be returned to stock

Given that a customer buys a blue garment

And I have two blue garments in stock

And three black garments in stock.

When he returns the garment for a replacement in black,

Then I should have three blue garments in stock

And two black garments in stock

    <!--
    .csharpcode, .csharpcode pre
    {
    font-size: small;
    color: black;
    font-family: consolas, "Courier New", courier, monospace;
    background-color: #ffffff;
    /*white-space: pre;*/
    }
    .csharpcode pre { margin: 0em; }
    .csharpcode .rem { color: #008000; }
    .csharpcode .kwrd { color: #0000ff; }
    .csharpcode .str { color: #006080; }
    .csharpcode .op { color: #0000c0; }
    .csharpcode .preproc { color: #cc6633; }
    .csharpcode .asp { background-color: #ffff00; }
    .csharpcode .html { color: #800000; }
    .csharpcode .attr { color: #ff0000; }
    .csharpcode .alt
    {
    background-color: #f4f4f4;
    width: 100%;
    margin: 0em;
    }
    .csharpcode .lnum { color: #606060; }
    -->
    それぞれの物語にはタイトルと短い説明があります.一般的には、次のフォーマットがあります.
  • 実現のために・・・
  • 開発中の...
  • 機能がそうであることを願っています...
    • 説明は、所定のステップを含む一連のシーンを添付することによって、前置イベント、使用例動作、後置イベントなどを含む.
    BDDは、ユーザーが最も注目している行動から始めることを期待しているため、以下のガイドラインを堅持しなければならない.
  • 最も重要な特性を探し出す;
  • それに基づいて最も重要なシーンを見つけます.

    • これにより、ユーザーのニーズの観点から開発を行い、本当に有効な目標に注目することができます.
     

    結論


    多くの人がBDDを「正しいTDD」と見なしているのは、ユーザー中心の最適な開発実践が含まれているため、従来の技術案を中心とした方式を変え、ユーザーの意図をトップにしているからだ.そのため、より良いソフトウェアを作成し、ユーザーのニーズを実現するのに役立ちます.
     
    ソース:http://blog.codeship.io/2013/04/22/from-tdd-to-bdd.html
    WEBフロントエンドの自動化テスト-Yeti編
    SpringBoot基礎教程(十七)——ログとの結合