Mail::fake()の挙動確認
- 実際のメール送信処理を行う代わりにモック（偽物の動作を模擬したオブジェクト）を使う
- メールが正しく送信されるかどうかを確認できるだけでなく、メールが実際に送られてしまうことによる副作用を避けることができる

参考文献

https://laravel.com/docs/9.x/mocking#mail-fake

テスト雛形ファイルを生成する

Featureテストファイルの生成

php artisan make:test SampleTest

ディレクトリ指定
- ユーザーディレクトリ配下

php artisan make:test User/SampleTest

参考文献

hata8341

特定のテストメソッドを実行する

実行ファイル：tests/Unit/SampleTest.php
実行メソッド：sample1

php artisan test --filter sample1 tests/Unit/SampleTest.php

hata8341

Mail::assertSent()について

メールが正しく送信されたことを確認する
引数としてクロージャーを受け取り、このクロージャーに送信されたメールオブジェクトを引数として渡す

Mail::assertSent(function (OrderShipped $mail) use ($order) {
    return $mail->order->id === $order->id;
});

第一引数にMailオブジェクト、第２引数にInt値をもたせることでメール回数を検証することができる

 // Assert a mailable was sent twice...
        Mail::assertSent(OrderShipped::class, 2);

参考文献

https://laravel.com/docs/10.x/mail#testing-mailable-sending

hata8341

Mockeryエラーについて

Error”””
Mockery\Exception\InvalidCountException

Method send(<Any Arguments>) from Mockery_2 should be called
exactly 1 times but called 0 times.
”””

詳細

このエラーは、モックオブジェクトを使ってユニットテストを実行する際に生じるものです。Mockeryというフレームワークが関与しており、PHPでよく使われます。

具体的には、テスト中に特定のメソッドが予想通りに呼び出されることを確認するために、モックオブジェクトを使用しています。このエラーメッセージは、「send」というメソッドがテスト中に正確に1回呼び出されるべきであると指定されていたにもかかわらず、実際には0回しか呼び出されなかったことを示しています。

これは次のような状況で生じます。たとえば、次のようなコードがあるとします：

$mock = Mockery::mock('MyClass');
$mock->shouldReceive('send')->once();

ここでは、モックオブジェクト$mockが作成され、そのsendメソッドが正確に1回だけ呼び出されるべきであると指定されています。しかし、このテストの実行中にsendメソッドが一度も呼び出されなかった場合、上記のエラーメッセージが表示されます。

解決策としては、テストが実行されるコードを確認し、sendメソッドが適切に呼び出されるように修正するか、またはテストの期待値を変更する必要があります。それは、sendメソッドが呼び出される回数の予想を修正するか、あるいはsendメソッドが呼び出されないことを期待するようにテストを変更するかのどちらかです。

解決策

異常系のテストでこのエラーが発生した。
処理の関係で異常系の場合はsendメソッドには到達しない
今回の異常系のテストではモックの生成はしない方針で回避した

hata8341

shouldReceive()の挙動について

shouldReceive()は、LaravelのテストユーティリティであるMockeryによって提供されるメソッドの一つです。これは、モックオブジェクトが特定のメソッド呼び出しを"受け取る"べきであることを指定するために使用されます。

shouldReceive()を使うことで、開発者はあるメソッドがテスト中に呼び出されるべきであることを示すと同時に、そのメソッドが返す値も定義できます。これは、外部の依存関係を持つ関数やメソッドのテストを独立に行うのに役立ちます。

以下に、その使用例を示します：

$mock = Mockery::mock('SomeClass');
$mock->shouldReceive('someMethod')
     ->once()
     ->andReturn('value');

上記のコードでは、まずSomeClassのモックオブジェクトを作成します。次に、そのモックがsomeMethodメソッドを一度だけ受け取るべきで、そのメソッドが呼び出されたときには文字列'value'を返すべきであると指定しています。

このようにshouldReceive()を使用することで、特定のメソッドが呼び出されたときの動作を制御し、テストをより柔軟に行うことができます。

hata8341

git cherry-pick について

他のブランチのコミットを取ってこれる
- 取ってきた大本（参照元）のコミットは改変されない

git cherry-pick Aのコミットid Bのコミットid Eのコミットid

引数には複数のコミットIDをもたせることができる
先頭から順番にブランチにマージされる

参考文献

hata8341

git fsckについて

addしたファイルを削除した場合でも、復旧することができる

hata8341

Mockをグローバルの状態ではなく、テストメソッド内で単一の状態として扱う

@runInSeparateProcess:他のテストプロセスと分けて実行する
@preserveGlobalState disabled：グローバルのステートを無効にする

参考文献

hata8341

.env.testingについて

Laravelフレームワークにおける .env ファイルは、アプリケーションの環境変数を管理するためのものです。これにより、開発、テスト、本番などの異なる環境で異なる設定を使用できます。

特に .env.testing ファイルは、テスト環境に特有の設定を格納するためのものとして考えられています。このファイルには、テストデータベースの接続情報や、テスト時に使用するAPIキーなど、テスト実行時のみに適用したい設定が含まれることが多いです。

例えば、あなたがPHPUnitなどのテストツールでテストを実行する際、Laravelは .env.testing の内容を優先して読み込むことで、テスト専用の設定を適用することができます。ただし、実際に .env.testing ファイルが使用されるかどうかは、テスト実行時の設定やコマンドラインオプションによって異なります。

一般的な使用例:

テスト用のデータベース接続情報（例：DB_CONNECTION, DB_HOST, DB_DATABASE など）。
テスト用のAPIキーやサービスのエンドポイント。
テスト環境専用の設定やフラグ。

このような環境ごとの設定を切り替えることで、実際の本番環境の設定やデータを誤って変更することなく、テストを安全に実行することが可能となります。