振る舞い駆動開発(Behavior-Driven Development / BDD)とは

1.はじめに

テストコード。

開発期限が迫っているため書く余裕がない、ということはママあると思いますが、
個人的には書けるなら書いた方がいいかなと思っています。

テストを書ける状態のプロダクトコードになっていないなら、まずはリファクタから頑張る。。！
Baby-Steps で KAIZEN していくしか。。！

本ポストではテストコードを書くメリデメを含め、TDDの一流派のBDDについて書いていきます。

2.テストコードを書くメリデメ

個人の見解ですが、以下のようなメリデメがあるのではと考えています。

メリット
- テストで担保されている箇所に関しては恐れることなくロジック変更ができる
- 仕様を把握しないとテストが書けないため、逆に言うとテストを書く段階で仕様の認識漏れが減る
- テスタブルなコードになるため、コードの結合度や凝集度がより適切になり、コードの品質が高くなる
デメリット
- プロダクトコードのみを書く場合と比べると、短期的な開発スピード(特にコードをまずテスタブルに改修する場合)はもちろん遅くなる
- 学習コストがそれなりにある。チーム内でテストコードのお作法を合わせるのもコストがかかる
- 記述するコードが増えるため、コードレビューの負担がその分増える。巨大なプルリクエストだとテストコードまで見る余裕がないことも。。

3.TDDについて思うこと

短期的には成果が見えづらいため、焼畑的な開発を続けざるを得ない状況下においては、
取り入れるのが非常に難しいかなと思っています。

ですが長期的に見ると、低品質のコードや仕様の認識漏れやバグ修正などでの手戻りが減り、
スパゲッティコード化による属人化や開発速度の低下を防げるため、
プロダクト的にも、またもちろん精神衛生上にもとてもよいのではと思っています。

で、プロダクトコードを書いてからテストコードを書くのも速くていいですが、
可能であればテストコードを書いてからプロダクトコードを書いた方が品質が高くなるのでは
ないかと思っています。

プロダクトコードがある程度の品質で動いているなら
テストが書けない設計になっていても、多少サボってもいいと思ってしまうのが人間なのかなと🤔

もちろん、最初からテスタブルなコードを書けるなら順番はどちらでもいいと思います。
が、それなら最初からテストを書いた方が、リファクタによる手戻りの可能性は減りそうですね。

テストを書いてからプロダクトコードを書く開発手法をTest-Driven Development (TDD) と呼びます。

本ポストでは以下、TDDの一流派である Behavior-Driven Development (BDD) について
概要を書いていきます。

4.振る舞い駆動開発(BDD)とは

BDDはTDDの一流派ともいえますが、TDDに対し以下の実現のための原則や工夫が加えられています。

– テストを「振る舞い」（機能的な外部仕様）の記述に特化させる

– ユーザーの要求やアーキテクチャの設計仕様といった、より上位のインプットとTDDのテストにつながりを持たせる
https://www.atmarkit.co.jp/ait/articles/1403/05/news035_3.html

「コード自体の振る舞い」や「システム・アプリの振る舞い」に焦点を当てたテストを書いていくTDDの一流派です。

僕のイメージとしては、

テストファイルに仕様を書いていく
つまり、テストファイルを読めばコードやシステムの外部仕様が理解できる

ということを目指している開発手法、と捉えています。

目指しますが、個人的には、
ある程度以上複雑なアプリの場合、仕様を完璧に網羅するのは難しいと思うので、
コスパを鑑みた上である程度で妥協するのが現実的にはコスパがよいのではとも感じています。

特に動的なコンテンツ、インタラクティブなコンテンツは、
とかく考えうる仕様・条件・動きが膨大になりがちです。

妥協する場合、どの程度で妥協するかはチームやプロジェクト内で、
「価値のあるテストとは？価値のないテストとは？」などについて話し合い、
最適な落とし所の認識を合わせる必要があるかと思います。

5.振る舞い駆動開発のお作法

そもそも、振る舞い駆動開発(というより派生元のテスト駆動開発)は以下の3ステップの繰り返しで進めていきます。

Red
Green
Refactor

5-1.Red

Red では振る舞いテストを書きます。
システムがこの状態の時、この動作をすると、こう振る舞う、というテスト(つまり仕様)を書きます。

なので、ここではテストというよりは実質、仕様を書いていくという意識に近いかなと思います。

で、実装がまだないため、テスト実行すると必ずこけます。
テストがこけているのでIDEでは赤ポチがついているはずです。
なのでRed。

5-2.Green

次にGreenです。
こけていたテスト(つまり仕様)を通すように実装をします。
実装が終わった後にテストを回すと、赤ポチが緑ポチになります。
なぜならテスト(つまり仕様)を満たすように実装したからです。

5-3.Refactor

最後に、必要であれば実装をリファクタリングします。

これでおそらく、ある仕様を満たす最小限の実装ができたかと思います。

あとはこれの繰り返しです！

え、複数の出し分けの仕様があるのにこのままだと一つの条件しか考慮できておらず、マジックナンバーがある？
次のRed, Green, Refactor できれいに出し分け/リファクタすればいいでしょう！

こんな感じで、仕様を満たす最低限のロジックのみを書き、
それをテンポよく繰り返し改修していく。
仕様の解像度を徐々に上げていくような進め方。

それがBDD(TDD) かなと僕は捉えています。

6.一つ一つの振る舞いテストのお作法

一つ一つの振る舞いテストは以下の3つの手順で記述できると言われています。
Agile Allianceのメンバー Martin Fowler さんのブログより。

Given: システムがこの状態の時(前提条件)
When: この動作をすると
Then: このような振る舞いをする

これらを1セットとして、一つ一つの振る舞いに対してのテストを記述できるはずです。

テスト駆動開発 Kindle版
￥2,772

Amazon で購入

7.最後に

今ではテストを書かないとなんだか気持ち悪いと思えるようになりましたが、
当初はもちろん戸惑いました。

もちろんTDD/BDD が絶対正しいという訳ではなく、
コードの品質と、ある期間内での開発スピード感、どちらを重視するかによって
最適解は変わってくると思います。

以上、BDDについてでした.。
お疲れ様でした！