はじめに

近年、AgileやScrumの普及に伴って、振る舞い駆動開発(Behavior Driven Development、以下BDD)や受け入れテスト駆動開発(Acceptance test–driven development、以下ATDD)にも注目が集まってきました。

そこで本連載では、BDDやATDDとは何か、どのように活用すれば良いのか考えていきたいと思います。

本連載の構成は以下の通りです。

本連載のメインであるBDDやATDDは、テスト駆動開発(Test-driven development、以下TDD)から派生した考えです。つまり「TDDとは何か」という理解がないとBDDやATDDを理解することが難しくなります。そこで今回は、TDDとは何か、TDDの目的は何かについて改めて考えてみましょう。

本連載を読み始める前に確認してほしいこと

対象読者について

本連載では、以下のような読者を対象として考えています。
・TDDのやり方を知っている、もしくはTDDを実践している
・BDDという単語は聞いたことある
・BDDのやり方は知らない

本記事でTDDのやり方については語りません

本記事では、具体的なTDDのやり方については割愛します。
理由としては、既に素晴らしい教材がネット上にあるからです。特に、TDD Bootcamp 2020 Onlineの和田卓人さんによる基調講演(動画)は是非ご覧ください。文字上でTDDを語るよりも多くの有益な考え方が示されています。
本記事では、TDDのやり方を知っている前提で、なぜTDDを行なうべきか、何を目的としているのかについて話します。

TDDはテスト手法ではなく開発手法である

「TDDとは開発手法もしくは設計手法の1つである」という理解が必要です。特に、TDDという名前から「テスト手法の1つである」という勘違いが非常に多いです。

TDDとは、「テストの方法」ではなく、あくまでも「手段としてテスト(テストコード)を用いた開発方法」です。

TDDは以下の3つを満たしながら作成していきます。
・Red…設計の指針や直近のゴールを明確にする(そのためにテストコードを記述する)
・Green…ゴールを達成する(つまりテストコードがPassする)コードを愚直に実装する
・Refactor…ゴールを達成させたまま(つまりテストコードがPassしたまま)、実装したコードを改善していく

ゴールを示す具体的な手段としてテストコードを用います。

BDDを考案したDan Northも自身の記事「We need to talk about testing(邦訳:テストについて話し合わなくてはならない)」の中で、以下のように述べています。

TDD、BDD、ATDD、および関連するメソッドは、その名前が示すように、テストに取って代わるものではありません。これらは主に設計および開発手法です。
(中略)
プログラマーは自分が単体テストを書いていると思っています。そうではありません。彼らは、設計の指針となる簡単な具体例をテストコード形式で書いているに過ぎません。

続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。

SHARE

  • facebook
  • twitter

SQRIPTER

風間 裕也(かざま ゆうや):ブロッコリー

B-Testing

記事一覧

電気通信大学大学院修士課程修了。
B-Testingを開業し、「どのようにテストを考えればよいか」を社内外問わずエンジニアに日々お伝えしている。


【社外コミュニティ活動】
・WACATE(ソフトウェアテストをテーマとしたワークショップ)実行委員長
・JaSST Review(ソフトウェアレビューシンポジウム)実行委員長


【翻訳活動】
・Agile Testing Condensed(翻訳)
・A Practical Guide to Testing in DevOps(共訳)
・The BDD Books - Discovery(翻訳)

  • 新規登録/ログイン
  • 株式会社AGEST
#TAGS人気のタグ
RANKINGアクセスランキング
NEWS最新のニュース

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST