tadoumaです。
早いものでエンジニアになって5ヶ月、
最近、テストが通ったのに検証でエラーや不具合が起こることが増えました。
今回は、初心者に起こりがちな｢テストの想定漏れ｣について書いてみようと思います！

目次

1.はじめに　想定漏れについて
2.想定漏れパターン3選
3.最後に

1.はじめに　想定漏れについて

なぜテストが通っても検証環境でエラーになるのか。
それは｢自分が書いたテストの想定範囲が足りなかった｣からです。
特に初心者はまだ蓄積しているパターンが少ないため、想定が甘いことが多々あります。(ありました。。。)
今回の記事では、自分が実際にやらかした｢想定漏れ｣について紹介していきます。

2.想定漏れパターン3選

2-1.Carbonでの時間指定でハマった

なにが起こったのか

登録日から3日経過したユーザーに対し、リマインドメールを送信するバッチを作成した時、
それは起こりました。

登録日から3日前のユーザーを擬似的に作ります。
3日前はもちろん便利なCarbonで作成。

$test_user = factory(User::class)->create(['created_at' => Carbon::today()->subDays(3)]);

テスト通った〜〜〜〜！(ΦωΦ)

が、
検証環境でメールが届いてない、だと･･･？

なぜ起こったのか

単純明快！
0:00以外の時間を想定していなかった！
そのため、日付のカウントが1日ずれてしまっていました。

例)
今日の日付を12/15 0:00とした時、、、
A︰テストデータ(12/12 0:00)の場合
→12/15 　0:00と比較した時、その差は3日
B︰DBに実際にある日付(12/12 0:01)の場合
→12/15　0:00と比較した時、その差は2日と23時間59分

そのため、パターンBの場合はカウントした日付が2日になってしまい、送られないのです。

今回、テストデータはCarbonでの作成のため、
全て0:00の日付で作成されていて気づかなかったという･･･。

対処法

実コードは、取得した日付について、時間を0:00にするよう修正。

$created_at = Carbon::parse($user->created_at)->startOfDay();

テストは、0:00以外の時間を設定するよう変更。

Carbon::setTestNow(Carbon::create(2018, 12, 15, 0, 0, 1));

これで無事、日付のカウントが動くようになりました。
この日付の感覚、初心者だと最初はなかなか掴みづらい気がします。

2-2.null,0,削除パターン

なにが起こったのか

まず前提はこちら。
･メール送信バッチ
･ユーザーはアイテムを保持する
･アイテムには期限がある
･ユーザーは削除可能である
･アイテムの期限が切れそうなユーザーに｢アイテムを使ってください｣とメールを送る

テストでは、
･アイテムを保持するユーザー
･アイテムを保持しないユーザー
この2つを作り、それぞれ送られる/送られないをテストしました。

テスト通った〜〜〜〜！ヾ(ΦωΦ)/

と、思いきや。。。。。
またもや検証環境でメールが届いてない･･･？
エラーメッセージ、Trying to get property of non-object
が出てしまいました･･･

なぜ起こったのか

ユーザーが削除された場合を考えていなかった。

お察しの通りです。
(ユーザーが削除されたらアイテムも消そうよ、というツッコミは一旦置いておいて。。。)

今回、こんな感じでメールアドレスを取得しようとしていました。

$item->user->email;

期限間近のアイテムを取得
↓
そのアイテムの持ち主を取得
↓
持ち主のメールアドレスを取得

ま〜当然ユーザーいなかったら、nullからemailを取ろうとしているので無理ですね！
すみませんでした！！！

対処法

実コードは、$userがなかったときの処理を追加。

if(empty($user)){
    return false;
}

テストでは、削除されたユーザーを入れておく。

$test_user->delete();

これで完了！
私は｢nullだったら｣｢削除されたら｣｢0だったら｣といった想定を忘れて
検証環境でエラーになることが多かったです。。。

2-3.否定アサーションと接続詞

なにが起こったのか

送られてはいけない条件のユーザーに、メールが送られていないことをテストしていた時、、、

※$no_send_user1と$no_send_user2は、どちらも｢送られてはいけない｣条件のユーザー

Mail::assertNotQueued(TestMail::class, function($mail) use ($no_send_user1, $no_send_user2){
    return $mail->hasTo($no_send_user1->email) and
    $mail->hasTo($no_send_user2->email);
});

はい、

テスト通った〜〜〜〜！ฅ(* ΦωΦ *) ฅ

と、思った時期が私にもありました。
しかし実際にはメールが送られてしまっていたのです････
原因は単純だったので置いておいて、｢なぜこれが検知できなかったか｣で考えてみます。

なぜ起こったのか

not A and B　と、not A or Bを誤認していた。
あ、こいつ文系だなって感じですね。
ただ私これ、専攻の英語でも勉強してた･････。

平たく言うと、
not A and B→部分否定
(Aでない　または　Bでない)
not A or B→全否定
(Aでない　かつ　Bでない)
これを取り違えていたのです。

上記のコードの場合、
$no_send_user1と$no_send_user2、
どちらか一方に送られていなければ、それでTrueを返していた、ということ。

つまり、$user1と$user2　どちらにも送られていないことを確認したい場合、
andではなくorで繋げなければいけなかったのです。。

対処法

上記で言っちゃいましたが、orで繋げることです。

Mail::assertNotQueued(TestMail::class, function($mail) use ($no_send_user1, $no_send_user2){
    return $mail->hasTo($no_send_user1->email) or
    $mail->hasTo($no_send_user2->email);
});

知らないと一度はやりそうなミス。。

3.最後に

自分の想定範囲が甘いと、
せっかくのテストが意味を成さなくなってしまいます。

では、どうすれば想定漏れがなくなるのか？
【初心者が気をつけること】としては、
･他の人のテストコードを読み込む。必ず｢ここまで想定する？ここまで場合分けする！？｣って思うことがあるはず。
･テストケースを作成する際、場合分けした後に｢もし○○だったら｣を思いつく限り書いてみる
(今回だと、｢もしユーザーが削除されていたら｣を考えつけていればエラーは起こらなかった)

簡単ですが、このあたりが対処法として考えられるかと思います。
私も今後｢もし○○だったら｣を考えられるよう、日々精進していこうと思いました。

今回の記事が少しでもなにかの参考になれば幸いです！