学習メモ：WEB+DB PRESS Vol.69(Part.1)

JUnit記事について

第６章cucumber-junitによる振舞駆動開発 - JUnitを活用した受け入れテストの自動化

受け入れテストの自動化についてはあまり関心がなかった為、学習する時間を割いて来なかった。
しかし、今月のWEB+DB PRESS Vol.69でその部分を言及していた為、まとめておく。

以下、引用

• • • • • • • • • • • • • • • • • -

従来の開発では、開発の最終局面でソフトウェアを結合してテストしてきた。
その際のテストは、設計書や要件定義書に定義された仕様を満たしている事を検証する為に行われる
ものが多く、顧客の要求を満たしているとは限りませんでした。

• • • • • • • • • • • • • • • • • -

・所感
　要件定義書に定義された仕様というのは、顧客の要求である為、
　従来の開発で要件定義書を満たしていれば、顧客の要望は満たしている気がするのだが、
　何が原因で、顧客の要望を満たしているとは限りません。と言及しているのか。ちょっと不明。

以下、引用

• • • • • • • • • • • • • • • • • -

早い段階で自動化された受け入れテストを実施する為には、振舞駆動開発（BDD：Behaviour Driven Development）が有効。
※受け入れテスト駆動開発（ATDD：Acceptance Test Driven Development）とも言う。

• • • • • • • • • • • • • • • • • -

以下、引用

• • • • • • • • • • • • • • • • • -

振舞駆動開発では、「Given/前提」、「When/もし」、「Then/ならば」が重要

• • • • • • • • • • • • • • • • • -

・所感
　振舞駆動開発とテスト駆動開発は組み合わせて開発を行うべきだと個人的には考えているが、
　テスト駆動開発を行いつつ振舞駆動開発を行うのは、
　現場のリソースが不足している場合は、厳しいような気がするなぁ。

　個人的には、外部設計が完了した段階で、振舞駆動開発は実施できる。
　その開発が平行で走っている場合は、顧客へのフィードバックも早急に対応できるし、
　何より開発者が森を見つつ開発が出来るが良いと感じている。

　とはいえ、プログラミングが大好きな人達は、
　外部設計に関する部分にはあまり興味がなくて、素敵なコードを書く事に熱心になりがちだったりする。
　なので、あまり意味はないのかも知れないが、顧客折衝を行う立場の人間からすると、
　振舞駆動開発は、現場エンジニアの仕様理解力を高める仕組みとして有効だと思う。

WEB+DB PRESS Vol.69