テスト設計パターン（仮）を考える会 考えてみたメモ 仕様スニペット001

#テスト設計パターン を考えるための「仕様スニペット」の例を書き下してみたので、みなさんテスト観点なりテストケースなりを考えてみてください！ リプでも引用RTでも大丈夫です。
週明けまでにいくつかでも集まったら、まとめてみますよ～。
…わたしのやりたいこと、伝わるだろうか…？
伝われ…！ https://t.co/RJ7JXRwfBe pic.twitter.com/p1RcWAclAl

— Kazu SUZUKI (@kz_suzuki) April 18, 2024

こちらについて考えてみました。

まずは仕様の理解から

• 親子関係にあるAとB（部署と従業員）

  • ここでは素直に人事労務システムの部署とそこに所属する従業員と捉えます

• 親Aの数は0〜48

  • 数字が出てきた時点で境界値分析を使うことが確定します

  • 0部署、1部署、n=48部署

• 子Bの数は全体で0〜128

  • 数字が出てきた時点で境界値分析を使うことが確定します

• AあたりのBは0〜16

• 子Bは子Aを必ず1つ持つ

  • 部署に所属していない従業員はいないし、兼務もない。

• 子Bはいつでも削除可能

  • 退職はいつでも可能と。手続きがないのが羨ましいですね。

  • 物理削除なのか、論理削除なのか考える必要がありそうです。

• 関連づく子が一人でもいる限り、親を削除することはできない

  • ということは、おそらく物理削除でRESTRICT制約が入っています。

ここから、作られるであろうシステムを想定していきます。

データ構造を考える

前提としてデータ構造を確認します。以下でなかったら考え直し。

・部署テーブル（departments）と従業員テーブル（employees）がある
・両エンティティが直接親子関係ということは、中間テーブルは存在しない（要確認）
・よって、従業員テーブルに部署レコードのidを持つことになる
・つまり、一人の従業員が複数部署に所属する可能性はデータ上そもそも考えなくていい可能性が高い

作る機能群

画面からAPIをfetchしてもろもろやっていくシステムで考えます。
多分部署と従業員でそれぞれCRUDに対応したAPI作ると仮定します。

• 部署（A）の表示

• 部署（A）の作成

  • 部署に親部署があるとは書いてないですが親子関係にすると「兼務」に引っ掛かる気がするのでないことにします

• 部署（A）の更新

  • 今回の課題とはあまり関係がなさそうなので省略

• 部署（A）の削除

• 従業員（B）の表示

• 従業員（B）の作成

• 従業員（B）の更新

  • 部署の移動があるので考慮（後から追加）

• 従業員（B）の削除

で、「それらを呼び出す一つの画面がある」と仮定します。

テストケースを考える

境界値でいけそうです。一部デシジョンテーブルを使います。

部署（A）一覧の表示（GET /api/v1/departments）

• 0件（empty UIの表示）, 1件, 48件まで出力できること

• 削除した部署が表示されないこと

部署（A）詳細の表示（GET /api/v1/departments/:id）

• 0人（empty UIの表示）, 1人, 16人まで出力できること

• 削除した従業員が表示されないこと

• 削除した部署の場合404レスポンスが返ること

部署（A）の作成（POST /api/v1/departments）

• 0件、47件のとき部署を作成できること

• 48件以上のとき、400レスポンスとエラーメッセージが返ること

部署（A）の削除（DELETE /api/v1/departments/:id）

• 該当の部署が削除済みのとき、404レスポンスとエラーメッセージが返ること

• 該当の部署の従業員数が1以上の場合、400レスポンスとエラーメッセージが返ること

• 該当の部署の従業員数が0の場合、204レスポンスが返されること

従業員（B）一覧の表示（GET /api/v1/employees）

• 所属している従業員が0件（empty UIの表示）, 1件, 128件まで出力できること

• 削除した従業員が表示されないこと

従業員（B）詳細の表示（GET /api/v1/employees/:id）

• 未削除の場合従業員の詳細と200レスポンスが返ること

• 削除した従業員の場合404が返ること

従業員（B）の作成（POST /api/v1/employees）

• 0件、127件のとき従業員を作成できること（201）

• 従業員が全体で128件以上のとき、400レスポンスとエラーメッセージが返ること

• 所属予定の部署の所属従業員が15人のとき登録できること

• 所属予定の部署の所属従業員が16人以上のとき400レスポンスとエラーメッセージが返ること

• デシジョンテーブルで整理した方がいいかもしれません。

従業員（B）の更新（DELETE /api/v1/employees/:id）

• 該当の従業員が削除済みのとき、404レスポンスとエラーメッセージが返ること

• 該当の従業員が存在する場合、かつ該当の部署が15人のとき200レスポンスが返され部署が移動されること

• 該当の従業員が存在する場合、かつ該当の部署が16人のとき400レスポンスとエラーメッセージが返ること

• デシジョンテーブルで整理した方がいいかもしれません。

従業員（B）の削除（DELETE /api/v1/employees/:id）

• 該当の従業員が削除済みのとき、404レスポンスとエラーメッセージが返ること

• 該当の従業員が存在する場合、204レスポンスが返されレコードが消えること

今回は考えませんが、受け入れテストで「まっさらなところから部署を登録して行ってマックスの件数まで登録、従業員の削除と部署の登録まででき諸々のUIがデザイン通りであること」までテストしたら完了です。

考えながら思ったテスト観点の決め方

• 数字が出てきた時点で境界値分析が必要だと考えました。

• 状態遷移も考えましたが、単純に人数だけなので要らないと考えました。

• 親あたりの子の制約があるので従業員の追加と更新に関してのみデシジョンテーブルを使うと思います。（複数の条件がある場合はデシジョンテーブルを使う）

• 追加と削除と聞くと、CRUDの他の（RとU）も要らないか考えました。

• 中間テーブルの可能性を結構考えましたが、問題文を読んで意図的に削除しました。