テスト設計パターンに挑戦「仕様スニペット001」をやってみる

https://twitter.com/kz_suzuki/status/1780943509434020157?s=61&t=e2tnn7sBBU0nVfdQcHjKcA

これは禊です。

私

入力のパターンを考える

最初に考えるのは入力のパターンでした。
でも、この場合入力するのは「親」か「子」かというプロパティのみっぽいです。
ですので以下のテスト条件を確認します。
「親としてAを追加できること」
「子としてBを追加できること」
ただし、子の条件には「必ず1個の親を持つ」とあるので、以下のテスト条件として書き下します。
「1個の親を持つBを子として追加できること」
この時、ついでに仕様の裏返し(追加できないこと)も確認します。
「親を持たないBを子として追加できないこと」

追加の動作の入力として、複数個追加できるかどうかが気になりますが、ここでは1つしか追加できないと仮定します。

削除も1つしか削除できないと仮定します。
「親Aが1つ以上ある場合、親Aを削除できること」
「子Bが1つ以上ある場合、子Bを削除できること」
この場合も親の削除には条件があるので、以下のテスト条件として書き下します。
「親Aが1つ以上あり、子がない場合、親Aを削除できること」
裏返しも
「親Aが1つ以上あり、子がある場合、親Aを削除できないこと」

最大値と最小値を考える

親は0-64、子は0-128という全体の数があるみたいです。こちらはそれぞれ確認します。
最大値を確認します
「親Aを64個まで追加できること」
「子Bを128個まで追加できること」
変な感じですが、0個でもいけることは明示的に確認します。
ただし、０にできる動作は削除なので、削除に言い換えます。
「親Aを0個まで削除できること」
「子Bを0個まで削除できること」

最大数を超過した場合も確認しますか。
「親Aを65個まで追加できないこと」(エラーを出すことでもいい)
「子Bを129個まで追加できないこと」(エラーを出すことでもいい)
削除の場合は日本語をちょっと工夫します。
「親Aを0個から削除できないこと」(エラーを出すことでもいい)
「子Bを0個から削除できないこと」(エラーを出すことでもいい)

また、子は必ず親を持ち、親は子を0-16まで持つので、この最大値を確認します。
「親Aは子Bを16個まで追加できること」
「親Aは子Bを0個まで削除できること」

最大値を超過。
「親Aは子Bを17個まで追加できないこと」(エラーを出すことでもいい)
「親Aは子Bを0個から削除できないこと」(エラーを出すことでもいい)

コンテキストの追加

初期状態

実は、この例では初期状態について定義されていません。
最初からレコードを持っていることを前提として作られているかもしれないので、以下のテスト条件を勝手に追加します。
「初期状態は親Aの数は0であること」
「初期状態は子Bの数は0であること」

追加削除のカウント方法

削除された場合ってどのように削除されるのでしょうか。
削除はしたけど、数をカウントするカウンタがあるかもしれません。
あるいはDBだと仮定して主キーとして採番した場合、削除は論理削除でレコードとして残ってしまい、誤ってレコード自体を見に行っているかもしれません。
「親Aを64件追加した状態で、1件削除後に、1件追加できること」
「子Bを128件追加した状態で、1件削除後に、1件追加できること」
「親Aは子Bを16個まで追加した状態で、1件削除後に、1件追加できること」

追加でも同じ判定をしていないか確認してみます。
「親Aを64件削除した状態で、1件追加後に、1件削除できること」
「子Bを128件削除した状態で、1件追加後に、1件削除できること」
「親Aは子Bを16個まで削除した状態で、1件追加後に、1件削除できること」

やりたかったけどできなかったコンテキスト

参照・更新可能なDBだと思った場合

複数人で操作可能なDBだと思った場合

仕様変更して、複数個の追加/削除が可能だった場合