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

亀岡的プログラマ日記

京都のベッドタウン、亀岡よりだらだらとお送りいたします。

TDDBC Osaka 2.1 反省会①

TDDBC Osaka 2.1パッチに参加してきました。個人的なテーマは


  • F# + NaturalSpecでやる

  • 原因結果グラフツールCEGTestを使ってテスト設計してみる


だったのですが、なんとまぁどちらも全然活用できず、残念な結果に。というわけで反省会。まずはCEGTestから。

原因結果グラフって?

  CEGTestを知ったのはTFSUG Osaka夏の陣で@yasuohosotaniさんが後輩の方々と一緒に紹介されていたものです。つまり4日前です。

  そんな状況ですので、そもそも何のためにつくるんだ?という所から必死で一夜漬けしたわけですが。3日なにしてたんだとか言わないで><

  簡単に言うと、原因・結果グラフからディシジョンテーブルを作ってくれるのがCEGTestです。原因・結果グラフってのはこういうやつね。

image

  これから、ディシジョンテーブルを生成してくれます。つまりどんなテストケースを作ればいいのかを教えてくれます。。。と書いても有難味が分かる人はあんまりいないのです。僕も勝手にグラフから出来上がるのはすげーすげーと見てたんですが。。。

うん、これってどう使うの(´・ω・`)???

まずはFizzBuzzから。。。

原因結果グラフを書いてみよう

  というわけでまずはプログラマの基本、FizzBuzzから。FizzBuzzの基本、


  • 3の倍数でFizz

  • 5の倍数でBazz

  • 両方でFizzBazz

  • それ以外は普通の数字


というのをとりあえず素直に書いてみましょう。


f:id:posaunehm:20120626011357p:plain

その時のデシジョンテーブルというのはこうなっています。


f:id:posaunehm:20120626011433p:plain

この#1〜#4の4列の条件がテストケースとなるわけですね。なるほど。確かにFizzBuzzの全条件である

3の倍数であり5の倍数でない

5の倍数であり3の倍数でない

3と5の倍数である

3の倍数でも5の倍数でもない

が表現できてますね。ふむふむ。

。。。ん(・へ・)?

全部を表現できないよね?

  んで、ようやく気づいたんですが、これってFizzBuzzの中でも各数字に対して個々にどういう文字を出力するか?というかなり個別のことにしか書けないわけです。例えば数字を列挙することそのものなどは(当たり前だけれど)デシジョンテーブルによって決められるテストケースには入って来ません。

  つまりは、これも使いドコロなんですよね。ツールの力を借りないと漏れちゃいそうな条件網羅を扱うのに優れている、というころなんだと理解しました。

んでTDDBC 2.0の課題で使ってみる

  TDDBCの課題はこんなかんじでした
んで、これから原因結果グラフなんですが。。。例えばステップ1~2の硬貨の投入、は考えられはするわけですよ。でも・・・ねぇ・・・


f:id:posaunehm:20120626011958p:plain

コレに意味があるかと言われると正直微妙。例えばここにもう2〜3条件入ると変わってくると思うんですが。あえて使うとしたらここかな、と思ったのがステップ3。

ステップ3 購入


  • 投入金額、在庫の点で、コーラが購入できるかどうかを取得できる。

  • ジュース値段以上の投入金額が投入されている条件下で購入操作を行うと、ジュースの在庫を減らし、売り上げ金額を増やす。

  • 投入金額が足りない場合もしくは在庫がない場合、購入操作を行っても何もしない。

  • 現在の売上金額を取得できる。

  • 払い戻し操作では現在の投入金額からジュース購入金額を引いた釣り銭を出力する。


太字強調したあたりがなんか書けそうですね。そこら辺を見ると、


f:id:posaunehm:20120626012519p:plain

とまぁこんなかんじにかけて、ディシジョンテーブルも


f:id:posaunehm:20120626012614p:plain

こんな感じになります。ちょっと1つずつ見てみましょう。



  • ♯1:在庫有り、金額が購入可能で購入ボタンを押した時のシナリオ

  • ♯2:在庫有り、金額が購入不可能で購入ボタンを押した時のシナリオ

  • ♯3:在庫なし、金額が購入可能で購入ボタンを押した時のシナリオ

  • ♯4:在庫なし、金額が購入不可能で購入ボタンを押さなかった時のシナリオ


お・・・押さなかった時・・・?(;・∀・)

そうか、原因に書いちゃってるからそうテストシナリオに出ちゃうんですよね。でも押さなかった時って、メソッドが呼ばれなかった、ということでいいのか、な?

これはPCソフトウェアに限っては微妙に感じますね。自販機オブジェクトを作っただけ、みたいなのことを考えるかというと多分考えないんですよね。初期状態をチェックするテストは書くかもしれませんが、それは”押さなかった”テストとはまた違う気がします。組み込みなんかではボタン操作はフラグや割り込みなので、割と自然に思えるかな、という気もしますが。

というわけで、TDDBCの課題ではちょっとうまく使うのは難しそう。もっと計算条件とかがややこしく代わるような文脈とか、ホントにフラグだけですべてを管理するシステムなら別かもしれませんが。

というわけで、とりあえずこんなとこを読んで勉強すればいいのかな・・・?