The Codest
  • 会社概要
  • サービス
    • ソフトウェア開発
      • フロントエンド開発
      • バックエンド開発
    • Staff Augmentation
      • フロントエンド開発者
      • バックエンド開発者
      • データエンジニア
      • クラウドエンジニア
      • QAエンジニア
      • その他
    • アドバイザリー
      • 監査&コンサルティング
  • 産業
    • フィンテック&バンキング
    • E-commerce
    • アドテック
    • ヘルステック
    • 製造業
    • 物流
    • 自動車
    • アイオーティー
  • 価値
    • CEO
    • CTO
    • デリバリー・マネージャー
  • チーム
  • Case Studies
  • ノウハウ
    • ブログ
    • ミートアップ
    • ウェビナー
    • リソース
採用情報 連絡先
  • 会社概要
  • サービス
    • ソフトウェア開発
      • フロントエンド開発
      • バックエンド開発
    • Staff Augmentation
      • フロントエンド開発者
      • バックエンド開発者
      • データエンジニア
      • クラウドエンジニア
      • QAエンジニア
      • その他
    • アドバイザリー
      • 監査&コンサルティング
  • 価値
    • CEO
    • CTO
    • デリバリー・マネージャー
  • チーム
  • Case Studies
  • ノウハウ
    • ブログ
    • ミートアップ
    • ウェビナー
    • リソース
採用情報 連絡先
戻る矢印 戻る
2016-08-19
ソフトウェア開発

レール上のBDD

ミハエル・クレゼレフスキ

今日のプログラマーは、日常業務でますます多くのアジャイルプラクティスを使用している。標準的なソフトウェア開発ライフサイクルに従ったプロジェクトでさえ、アジャイル・プラクティスを取り入れることで恩恵を受けることができる。自動テストとTDDは、私たちの仕事に自信をもたらし、既存の機能に対する修正の実装を容易にし、しばしばより良いコード設計へと導いてくれた。しかし、今はそれだけでは不十分だ。BDDはTDDの上に構築され、そのプラクティスに多くの価値を加える。BDDはTDDの上に構築され、そのプラクティスに多くの価値を加える。BDDはプロジェクトにユビキタス言語をもたらし、クライアントと開発者間のより良いコミュニケーションを可能にする。BDDは、プロジェクトマネージャーやリーダーに多くのことを提供するだけでなく、開発者の生活をより楽にしてくれる。BDDの原則に従うことで、明確な要件が得られ、テストは理解しやすくなり、ドキュメントの役割を果たすことができる。BDDはテスト対象のフォーカスを移し、テストすべきこと、つまり振る舞いをテストしているという自信を与えてくれる。

If you use TDD, starting with BDD will be easy – it’s basically a set of best practices for it. BDD has a set of simple rules, which tell how to write specs and what to test. Specifications are divided into three parts: Given (setting up test conditions), When (invoking action on subject) and Then (assertions). Tests should have descriptive names and existing test frameworks allow for using methods and assertions that are similar to natural language – all of which combined gives us tests that are readable by both technical and non-technical users. Good naming conventions prove useful during regression tests.

BDDには、テスト対象のガイドラインもある。TDDとは対照的に、BDDは実装のテストから振る舞いのテストへと焦点を移す。スペックは文書化され実行可能な顧客要求のようなものであるべきで、高レベルのものは受け入れテストとして機能すべきである。ゴールは、要求が変更されたときだけテストを変更する必要があるようにテストを書くことだ。BDDを使うことで、本当にカバーすべきものをテストしているという確信が得られるし、TDDよりも現実的なアプローチだ。

BDDが実際に使われているところをご覧になりたい方は、以下をお勧めします。 ルビー.パワフルで楽しく使える言語であり、優れたBDDツールセットを持っている。

キュウリ

CucumberはRubyのBDDのための最も人気のあるフレームワークです。Gherkinと呼ばれる特別な言語を導入しており、この言語でテストを記述します。RSpec とは対照的に、Gherkin で記述される機能はプレーンテキストです。 コードそのため、誰にでも、特にクライアントには理解できる。

キューカンバーの機能はこんな感じだ(例はキューカンバー・ウィキから引用):

 特徴何が望まれているかについての、簡潔だが説明的な文章
    この機能のビジネス上の価値のテキストによる説明
    その機能の適用範囲を規定するビジネスルール
    機能を理解しやすくするための追加情報

  シナリオ:決定可能なビジネス状況
    ある前提条件
    他の前提条件
    行為者による何らかのアクション
    そして、他の行動
    さらに別の行動
    テスト可能な結果が得られる
    そして、私たちがチェックできる他のことも起こる

  シナリオ別の状況
    ...

詳細は後述する。

Ruby on Railsでキュウリを使う

インストール

キュウリを使う最初のステップ プロジェクト をインストールする。この2つのgemをGemfileに追加するだけだ:

group :test do
  gem 'cucumber-rails', :require => false
  gem 'database_cleaner'
終了

を実行してバンドルする。 バンドルインストールそして、以下のコマンドでCucumberスクリプトとディレクトリを生成する:

rails generate cucumber:install

これによって config/cucumber.yml, スクリプト/キュウリ そして 機能/ディレクトリを含むことになる。 機能 ファイル、およびステップ定義とサポートファイルです。機能を実行するには、新しい rake コマンドを使います:

レーキきゅうり

特徴

機能について詳しく見ていきましょう。たとえば、定期的にニュースレターを送信したり、ユーザーが写真を公開したりすることです。1つの機能は複数のシナリオから構成され、この機能が異なるコンテキストでどのように機能するかを説明します。

RailsにおけるCucumberの基本的な使い方を示すために、ゼロから機能を書いてみましょう。このサンプル機能は、この記事の後半で紹介するアプリケーションで最初に書くものになります。このアプリケーションでは、ユーザがアイテムとショップ(ショップはアイテムを販売する)を作成し、ショッピングリストを作成できるようにします。

最もシンプルなバージョンでは、ショッピングリストを作成した後、アプリケーションはユーザーが欲しいアイテムがどのショップで最も安いかを表示します。

まず create_item.feature(アイテム作成機能 での 特徴 ディレクトリーディレクトリの先頭にある 機能 ファイルには 特徴 キーワードの後に、そのキーワードの短い説明が続きます。例えば

特集アイテムの作成

次の行では、この機能を実装するビジネスゴールを書きます。Cucumberは最初のScenarioの前に書かれたテキストを無視するので、何も書く必要はありませんが、間違いなく良いアイデアです。

   近隣のショップで販売されている商品を含むショッピングリストを簡単に作成するために
   ユーザーとして
   システムにアイテムを追加したい

このスニペットでは、ビジネス目標を記述する際によく使われるパターンを見ることができる。それは3つの部分から構成されています:なぜその機能が必要なのか、誰がそれを望んでいるのか、そしてそれは何なのか。もちろん、この形式に従う必要はありませんが、説明文の中にこれら3つの質問に対する答えを含めるようにしてください。

シナリオ

次に、いくつかのシナリオを書く。各シナリオは「シナリオ」というキーワードで始まり、複数のステップを含んでいる。

    シナリオ:ユニークなアイテムの作成
      ミルク」アイテムがあるとする
      メインページに行くと
      パン」アイテムを作成する
      アイテムリストに「パン」が表示される 

したがって、誰かがミルクというアイテムを作成した場合、パンを作成することは可能であり、アイテムリストにパンが表示されます。なぜなら、この事実は顧客にとって何の価値もないからである。

シナリオのステップでは、主に3つのキーワードを使う:

  • 与えられたシナリオに文脈を与える
  • いつアクションを記述する
  • では結果説明用

ここで重要なのは、Cucumberはキーワードで始まるステップを無視し、後の部分のみをマッチさせるということだ。従って、ステップを "And "で始めても構いません。正しいキーワードを選択するための唯一のルールは、シナリオが簡単に理解できることです。

ステップの定義

キューカンバーを実行すると、このように出力される:

[...]
特集アイテムの作成
  近隣のショップで販売されているアイテムでショッピングリストを簡単に作成することができます。
  ユーザーとして
  システムにアイテムを追加したい

  シナリオ:ユニークなアイテムの作成 # features/create_item.feature:6
    ミルク "アイテムがあるとする # features/create_item.feature:7
      未定義のステップ:"ミルク "アイテムがある" (Cucumber::Undefined)
[...]

これはCucumberが "There is a Milk Item "と言ったときの意味を理解していないからです。ステップに意味を持たせるには、ステップを ステップ定義 ディレクトリにある。

ステップ定義を整理するお勧めの方法は、ドメインごとに分けることです。例えば、我々が作成したステップのほとんどは、Itemドメインに属している。したがって step_definitions/item_steps.rb そこに以下のコードを置く:

"$name "というアイテムがあります。
  アイテムを作る: item, name: name
終了

$name "アイテムを作成する。
  を "#new_item "内で行う。
    名前 "に "name "を記入する。
    作成 "をクリック
  終了
終了

次に、「アイテムリストに "$name "が表示されています。
  .items "内で
    期待する(ページ).to have_コンテンツ名
  終了
終了

ステップの定義は通常Capybaraに基づいている。Capybaraをよく知らない場合は、この記事の最後にあるリンクを必ずチェックしてほしい。

もう1つ定義が必要なステップがあり、それはアイテムのステップには当てはまらない。それを main_page_steps.rb:

メインページに行く」ときは、次のようにする。
  root_pathにアクセスする
終了

結論

これは非常に単純な機能のための非常に単純なストーリーだ。その目的は、Cucumberで使われるBDDのコアコンセプトを示すことでした。しかし、良いストーリーを書くにはもう少し必要です。開発者として、考え方を完全に変える必要があります - 実装のことは忘れて、代わりにビジネスゴールに集中しましょう。Cucumberはプレーンテキストのストーリーを巧みに使うことで、この移行を簡単にします。

情報源、インスピレーション、興味深い読み物:

  • https://github.com/cucumber/cucumber/wiki/Cucumber-Backgrounder
  • https://github.com/jnicklas/capybara
  • https://blog.engineyard.com/2009/15-expert-tips-for-using-cucumber
  • http://blog.codeship.com/cucumber-best-practices/
  • http://www.elabs.se/blog/15-you-re-cuking-it-wrong
  • https://github.com/strongqa/howitzer/wiki/Cucumber-Best-Practices

関連記事

上昇する矢印とコスト効率や節約を象徴する金貨が描かれた減少する棒グラフの抽象的なイラスト。左上にはThe Codestのロゴと、ライトグレーの背景に "In Code We Trust "のスローガン。
ソフトウェア開発

製品の品質を落とさずに開発チームを拡大する方法

開発チームの規模を拡大中ですか?製品の品質を犠牲にすることなく成長する方法を学びましょう。このガイドでは、スケールする時期、チーム構成、採用、リーダーシップ、ツールなどの兆候に加え、The Codestがどのように...

ザ・コデスト
ソフトウェア開発

将来を見据えたウェブ・アプリケーションの構築:The Codestのエキスパート・チームによる洞察

The Codestが、最先端技術を駆使してスケーラブルでインタラクティブなウェブアプリケーションを作成し、あらゆるプラットフォームでシームレスなユーザー体験を提供することにどのように秀でているかをご覧ください。The Codestの専門知識がどのようにデジタルトランスフォーメーションとビジネス...

ザ・コデスト
ソフトウェア開発

ラトビアを拠点とするソフトウェア開発企業トップ10社

ラトビアのトップソフトウェア開発企業とその革新的なソリューションについて、最新記事でご紹介します。ラトビアの技術リーダーたちがあなたのビジネスをどのように向上させるかをご覧ください。

thecodest
エンタープライズ&スケールアップ・ソリューション

Javaソフトウェア開発の要点:アウトソーシングを成功させるためのガイド

outsourcingのJavaソフトウェア開発を成功させるために不可欠なこのガイドを読んで、The Codestで効率性を高め、専門知識にアクセスし、プロジェクトを成功に導きましょう。

thecodest
ソフトウェア開発

ポーランドにおけるアウトソーシングの究極ガイド

ポーランドのoutsourcingの急増は、経済、教育、技術の進歩がITの成長とビジネス・フレンドリーな環境を促進していることによる。

ザ・コデスト

ナレッジベースを購読して、IT部門の専門知識を常に最新の状態に保ちましょう。

    会社概要

    The Codest - ポーランドに技術拠点を持つ国際的なソフトウェア開発会社。

    イギリス - 本社

    • オフィス 303B, 182-184 High Street North E6 2JA
      イギリス、ロンドン

    ポーランド - ローカル・テック・ハブ

    • ファブリチュナ・オフィスパーク、アレハ
      ポコジュ18、31-564クラクフ
    • ブレイン・エンバシー, コンストルクトースカ
      11, 02-673 Warsaw, Poland

      The Codest

    • ホーム
    • 会社概要
    • サービス
    • Case Studies
    • ノウハウ
    • 採用情報
    • 辞書

      サービス

    • アドバイザリー
    • ソフトウェア開発
    • バックエンド開発
    • フロントエンド開発
    • Staff Augmentation
    • バックエンド開発者
    • クラウドエンジニア
    • データエンジニア
    • その他
    • QAエンジニア

      リソース

    • 外部ソフトウェア開発パートナーとの協力に関する事実と神話
    • 米国から欧州へ:アメリカの新興企業がヨーロッパへの移転を決断する理由
    • テックオフショア開発ハブの比較:テックオフショア ヨーロッパ(ポーランド)、ASEAN(フィリピン)、ユーラシア(トルコ)
    • CTOとCIOの課題は?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • ウェブサイト利用規約

    Copyright © 2026 by The Codest. All rights reserved.

    jaJapanese
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian es_ESSpanish nl_NLDutch etEstonian elGreek jaJapanese