アジャイル トランスペアレンシー ~アジャイル開発における透明性の確保について~

第5回 BDDとATDD

この記事を読むのに必要な時間:およそ 3 分

はじめに

本連載では,⁠透明性」というキーワードで,アジャイル開発について説明しています。前回は,テスト駆動開発(TDD)の持つ,開発を促進する設計作業としての側面にスポットを当てて説明しました。今回は,それらの考えを展開させてみたいと思います。具体的には,振る舞い駆動開発(BDD)と受け入れテスト駆動開発(ATDD)という二つのトピックを,ご紹介します。

テストのレビュー

前回,テスト駆動開発におけるテストを,設計作業であるとする考え方をご紹介してきました。これは,個々のクラスのインターフェース(=振る舞い)を,テストにより明確にしてゆくというものです。結果的に,作られたテストは,実装との乖離を自動的に検出できる設計書となります。

仕様変更やリファクタリングに伴うソフトウェアの改変に際して,バグの混入を自動的に検知できるので,実装と設計の同期が取れるという大きなメリットがあります。

しかし,当然デメリットはあります。第一に,テストの可読性の問題です。テストはコードになりますので,従来の設計書と比べると,読み易さやフォーマットの柔軟性という面で劣ります。また実際にテストを書く開発者の意識の問題もあります。テスト駆動開発というと,どうしても品質保証に必要なテストを想定してしまい,設計をわかりやすく表現しようという工夫はおざなりにされがちです。

第二に,テストのスコープの問題です。実際に記述されるクラスの振る舞いは,粒度が実装に寄りすぎていて仕様との整合性を確認しにくいといった側面があります。

アジャイル開発で設計情報の共有が上手くいかず,結局,従来型の重厚なドキュメント作成作業に従事することになる原因は,これらの問題点にあることが多いようです。アジャイル開発を進める上では,これらのデメリットを理解して上手に設計情報の共有を図る為の工夫が必要です。

さまざまな試みがなされていますが,今回は,テストの可読性の問題を解消する試みとして,振る舞い駆動開発(BDD) をご紹介します。そして,テストのスコープの問題を解消する試みとして,受け入れテスト駆動開発(ATDD)をご紹介します。

図1

図1

振る舞い駆動開発について

振る舞い駆動開発(Behavior Driven Development)とは,振る舞いを事前に実行可能な形式で記述し,そのあとで記述した振る舞いにのっとった形で実装を書いてゆく方法です。振る舞いの記述の実態は,xUnit 等のツールを使ったテストコードになりますので,やっていることの本質はテスト駆動開発(TDD)とは大差ありません。

主な特徴は以下のとおりです。

まず,一つ目にテストという用語を排した点にあります。テストとは設計である。という主張はやはり定義矛盾を含んでおり,納得はできても他人に説明しづらい側面を持っています。そこで,名称を変えることで,誤解を根本的に解消しようとしたものです。開発者も,テストを書くのではなく,クラスの振る舞いを設計する作業が,開発を駆動するということが,直感的に分かりやすくなります。何を目的として何をすべきなのかを明確にすることが大切で,テストは設計かそうでないか? などというのは,不毛な議論です。それを排したという意味で,個人的には大きな転回であると考えています。

「テスト」という用語の代わりに用いたのは,⁠ビヘイビア」という用語で,振る舞いのことです。振る舞いとは,オブジェクトの相互作用のことで,インターフェース(によって表現されるもの)と考えて構いません。

次の特徴として,クラスの振る舞いを表現しやすいように,より可読性の高い方法で振る舞いを書けるようにしたことです。具体的には,DSL と呼ばれる専用の言語で振る舞いを記述します。これにより,開発言語に精通していなくても,読みやすい設計を表現することが可能となります。また開発者側も,DSL という型にはまることで,作成したテストは,おのずと振る舞いを表現するようなものになり,TDD を行う技術者の TDD の熟練度に依存しなくても,分かりやすいテストが書けるようになります。

著者プロフィール

設楽秀輔(したらしゅうすけ)

1994年,慶応義塾大学経済学部卒業。エンターテインメント系企業にて経営管理を経験後,システムインテグレータとして金融アプリケーションなどのソフトウェア開発に従事。2007年,株式会社テクノロジックアートに入社し,現在に至る。

テクノロジックアートアジャイル開発グループグループリーダー。認定スクラムマスター。会計士補。

コメント

コメントの記入