#テスト設計パターン を考えるための「仕様スニペット」の例を書き下してみたので、みなさんテスト観点なりテストケースなりを考えてみてください! リプでも引用RTでも大丈夫です。
— Kazu SUZUKI (@kz_suzuki) 2024年4月18日
週明けまでにいくつかでも集まったら、まとめてみますよ~。
…わたしのやりたいこと、伝わるだろうか…?
伝われ…! https://t.co/RJ7JXRwfBe pic.twitter.com/p1RcWAclAl
こちらについてどのようなテストケースを書くのか考えてみようと思います。
「仕様スニペット」については思いつくほど実力がないので、自分の身の丈でということで考えてみようと思います。
1.仕様通りであることを確認する
正常系(笑)
動作だけにフォーカスしたデシジョンテーブルを作ってみました。
正常系だけやります"という方針で正常系の定義がなされなければこれだけで十分とされる現場があったりします。
異常系(笑)
異常系の動作も加えてみます。
この場合の異常系とは、エラーハンドルになりそうです。
※データが0の場合削除をトリガした時の動作について仕様に書いてませんでしたが、うっかり記載してしまいました
よく見たら抜けてるテストケースがあります。
間違ってたのでやり直した
上記が間違っていたので直しましたが、できないことと裏返しになっただけでこれって意味あるんだろうか?
追記
FBをもらいました。
指摘をいただいて気付いたのですが、条件指定部の内容がいけてなさそうです。
ありがとうございます。
— Kazu SUZUKI (@kz_suzuki) 2024年4月22日
「条件部」に書かれた複数の条件の組み合わせて動作が決まる場合に、デシジョンテーブルが合うのだと理解しています。今回の場合、部門と数と社員の数は独立した条件なので、わたしならそれぞれ単独で確認するだろうと考えました。