小学１年生でもわかる７月中に夏休みの宿題を終わらせる方法 | Moonmile Solutions Blog
の続き。
夏休み帳ですが、昨日学童に行った時に【全て】終わらせたそうです。
計画通りというか、計画倒れというか、計画無視というか、まぁ、早くやる分にはそれでOK。
さて、手早く済ませたのですが、実はいくつか残りがあります。
・答えが間違っているもの
・わからないので飛ばしたもの
IT の PG 工程で言えば、
・コーディングしたけど、間違っている（不具合の混入）
・コーディング抜け。
ですね。
■コーディング抜けの対処
これをどのように対処するかというと、「分からないの飛ばした」に関しては、ざっと見ると分かります。
答えが空欄になっていますからね。
PG で言えば、設計に書かれているけど、コーディングされていない、という【抜け】の問題です。
夏休み帳の場合は、あらかじめ答えを書く空欄が用意してあるので、ざっと見ただけで分かります。
なので、PG 工程の場合も似たようなことをすれば
・あらかじめ、クラス設計などでメソッドだけを用意しておく。
・あらかじめ、xUnit を作って、仮メソッドだけを用意しておく。
という方法です。箱だけ用意しておくと抜けがわかります。
前提条件として、コーディングの前にざっとですがクラス設計をしないといけません。
また、コーディング前のクラス設計が間違っていると修正が困難になります。
なのでオブジェクト指向設計なりデータ指向設計なりの構造設計をしておきましょうという話です。
■コーディングミスの対処
夏休み帳の答えが間違っている場合は、ざっと見ただけでは分かりません。
答えあわせをしないと駄目ですよね。
これがいわゆる単体試験の工程です。
答え合わせは、逐次やってもよいし、あとでまとめてやっても良いわけで、
・あとでまとめてやるのが、ウォーターフォールの従来型の工程
・逐次テストするのが、xUnit を使った工程
ってことです。
■クリア条件があるもの
さて、実はもうひとつの試験方法があります。
先の逐次テストの場合は、ホワイトボックス的に、期待値が明確である時に使います。
夏休み帳のような、答えが明確になっているものは、このタイプです。
もうひとつ、絵日記のような答えが明確ではないものがありますね。
絵日記の場合は、「ある程度の絵と文書が入っていること」がクリア条件になるのです。
これが、丁度、xUnit のブラックボックステストになります。
とある期待値をクリアしているかどうかということで、性能試験や受け入れ試験に使います。
受け入れ試験の場合は、実際のコードを使って xUnit でエミュレートをします。この場合、MVC モデルなどを利用して xUnit 使いやすくしておくことがベストですね。View/GUI 部分は手作業になることが多いので、xUnit に向きません。
絵日記の場合はどうでしょうか。見た感じ、できているかなぁ、というのもアリですが、もう少し期待値を決定してみると、
・絵の部分で、50% 以上、色が塗ってあること。
・日付が書いてあること。
・天気が書いてあること。
・文章が、50% 以上書いてあること。
のような感じで、View/GUI から切り離してテストが可能です。
まぁ、そんな厳密ではないけれど、こんな風なクリア基準があるはずです。
