読者です 読者をやめる 読者になる 読者になる

BDD的な視点からユニットテストの書き方を考えてみる

ユニットテストを修正していると、

  • テストが通らないけど、なんで通らないか分からない
  • どこまでが事前準備の部分かわからない
  • 挙句の果てには、テストを通るようにしてみたけど、今回の修正でいらなくなったテストケースだった

などなど、色々とめんどうな状況に遭遇します。

自分もよく可読性の低いテストケースを書いてしまうので偉そうなことはいえないのですが、なにを目的としているのか分からないテストケースはメンテナンスするのが非常に大変です。

 

で、これの対策というか何というかですが、

BDD的な視点からテストケースを書いてみると、もうちょっとましになるような気がします。

どんなシナリオを想定しているのかってことを、コードをぱっと見て分かるようになっていれば大分ましでしょう。

BDDだとその辺りを明示的に記述しなければいけないわけですが、

ただ単純にユニットテストを行う場合でも、そこんところを明確に出来れば大分違うのではと思ったりしてます。

 

 

 

 

ユニットテストをやるかやらないか

ユニットテストをやるべきかやらざるべきか。

大体の場合、やっておいたほうがいいとは思うんですが、

絶対やっておいたほうが得かって言われるとそうでもない気がします。

たまに、「TDD必須」とか、「ユニットテストは意味ない(理由はよく分からん)」

とか極端なことを言う人がいますが、そういうかたがたはすべからく、思考停止状態に陥っているので、そういう人とは特に議論をする必要はないでしょう。

 

TDDをやるかどうかは置いておいて、やっぱりユニットテストをやるとコストがかなりかかります。

工数が1.5倍~2.0倍くらいには膨れる気がします。

DBスキーマが変るたびにDBUnitのテストデータを修正するのはなかなか骨が折れます。なかなか精神的にくるものがあります。

 

もちろんその分のメリットもあります。

ある程度のカバレッジが維持されていれば、ロジックの修正ミスもすぐに検出できますし、リファクタリングをする際には、精神的な支えになります。

逆に、全てのコードは使い捨てだし、リファクタなんて絶対しないぜ! という場合には、あんまりメリットないような気がします。

 

まぁ、結局は費用対効果を見積もって、割に合うならやればいいし、合わないならやらないほうがいいわけです。

という何とも当たり前な結論に脳内で落ち着きました。

 

 

CodeZineにBDD(Jbehave)で寄稿しました

http://codezine.jp/article/detail/7585

 

とりあえず動かすことを最優先し、

Narrativeについては省略しました。