仕様スニペット004「サブスクリプションの自動更新」の #テスト設計パターンを考えてみる

JaSST北海道にかかりっきりで、テスト設計パターンに手をつけられていませんでした。
が、テスト設計パターンを考えることは、テスト設計という分野を今後充実させていくためにけっこう大事なことなんじゃないかと思っているので、仕様をもらえたら続けます。誰か、いい感じの仕様をくれ！！

docs.google.com

「テスト設計パターン」「仕様スニペット」って何？という方は、こちらの記事を先にご覧くださいね。

www.kzsuzuki.com www.kzsuzuki.com www.kzsuzuki.com

仕様スニペット004: 「サブスクリプションの自動更新」

第3回に続きこのネタも、かいりさんにいただきました。

以下に示す「サブスクリプションの自動更新」の仕様について、テスト観点を考えてください。

サブスクリプションプランには、月次更新と年次更新がある。

2024年1月1日に月次更新プランに登録した場合、次は2024年2月1日に更新される。

2024年1月1日に年次更新プランに登録した場合、次は2025年1月1日に更新される。

サブスクリプションの更新は、毎日定時にバッチ処理で実行される。
　ただし、特定の日付を指定して実行することもできる。

回答の例

鈴木の場合

やっぱり一番気になるのは日付なので、日付にフォーカスして考えてみました。

そもそもこの仕様1には「例示」があるだけで「ルール」が明示されていません。仕様を記述するうえでは、まずルールがあって、その理解を助けるための補足としての例示があるべき（個人の感想です）なので、例示しかない時点で設計した人と会話すべきでしょうね。

とはいえ今回は、

月次更新の場合は、登録日の月mに1を足して yyyy年m+1月d日に更新
年次更新の場合は、登録日の年yに1を足して yyyy+1年m月d日に更新

するのだろうと考えてみます。
パッと思いつくのは、以下の観点です。

m=1 なら m+1=2 でいいが、m=12 なら m+1 = 13 になってしまう。つまり、「年をまたぐ月次更新」はやりたい。
- 同じ発想で、yの上限も考慮すべきかもしれないが、リスクは低い？
d = 31, 30, 29 のない月がある。
- 月次更新の場合: 1/31、1/30、1/29（非うるう年）、3/31などは、mに1を足してもらうと該当する日付がない。
- 年次更新の場合: 2/29（うるう年）などは、yに1を足すと、該当する日付がない。
そもそも、登録した日付によってサブスクリプションの有効日数が異なることがおかしいのでは？
タイムゾーン、サマータイム、時差までは考えすぎ？

仕様2の方もいろいろありそうですが・・・。

𝓜𝓪𝓼𝓪𝔂𝓾𝓴𝓲 𝓣𝓪𝓬𝓱𝓲𝓫𝓪𝓷𝓪 さんの場合

https://x.com/taiden32/status/1800775149245051085

気になる点として、閏秒及び閏年のテストがどうなるのかというのと、2/29に初回登録した時の年次更新がどうなるのかが気になりました。

うるう「秒」までは考えていませんでした。60秒の次に00秒があるケースを考慮要・・・？

やまずんさんの場合

https://x.com/55_ymzn/status/1802702136222040173

字数内ジャストアイデアで
・定時のバッチ処理なので、何件くらい処理できるかの負荷的なところを見たいです。
・更新ということなので、登録だけでなく解約があると思いますがこの辺の動作も見たいです。
・日次処理ってことですが、31日に登録した場合、次はいつになるのかが気になります。
・うるう

わたしがサボった仕様2について、非機能要件をカバーしてくれました。

また、仕様に書かれた「登録」「更新」と本来セットになるべき「解約」について言及してくれています。CRUDのように、この手の「考えられる操作の一そろい」を考えることはとても大事ですね。すると同時実行を連想して、更新のバッチ処理と解約処理を同時に行ったらどうなる？と考えていくことになると思います。