試験するときに便利だったことまとめます。
Google Chromeのシークレットウィンドウ
こちらは使用している方も多いのでは。
chromeを履歴や Cookie がまっさらの状態で使用できるので、
２ユーザでログインしたい場合などに便利です。
社内システムのようなシステムでは役職や部署などによって実行権限が異なることが多いかと思います。
そのような場合に動作を確認するのに、ログイン→実行→ログアウト→別ユーザでログインといった手順で
確認するのはかなりの手間になります。
違うブラウザでログインすれば同様のことができますが、
やはり同じブラウザで確認したいことも多いのでそういった場合に活用できます。
権限者ごとのユーザ情報をまとめる
実際上記でもあるように、試験では様々な役職・部署の方で試験をしたい場合があるのですが、
多くなってくると頭では覚えてられないので、あると非常に助かりました。
日付基準のバッチは引数で実行する
日付基準の処理は試験が難しいです。
DBの値を使用して処理している場合は、その値を変えるだけなので良いですが
システム日付を取得して処理するといったバッチも多いはず。
そういったプログラム内部で日付取得し、後続処理とすると
いざ試験するときに非常にやりにくくなります。
なので基本的にはバッチに引数として日付を渡してあげることで試験しやすくなります。
引数なしの場合は現在日を取得し、ありの場合そちらの日付が優先されるイメージです。
この辺りはテスト容易設計にもつながる？
LaravelのCommandクラスの場合、こんな感じになる
php artisan command:test 20210721
正常系にもログ出力を埋め込む
よくあるパターンとして、プログラムで例外などの異常系が発生した場合にログを出力をする
という実装があると思います。
担当システムでもこの形で基本的には実装をしています。
ところがいざ実運用に入ってバグに悩まされた場合などには、調査用のログがあると調査が捗ります。
一旦リリースしてから調査用のログの埋め込むのは、コード変更・デプロイに結構工数がかかるので心理的な負担が重い。。。
今後は重要なユースケースやパフォーマンス面などで不安がある箇所などではログを入れてもよいかなと感じています。
具体的にはメソッドの開始、終了、DB処理、条件分岐周辺の部分にログ出力用のコードを埋め込んで
おくと便利そうです。
ただ、毎回処理ごとにログを吐くのは量が膨大になるため、ログレベルなどを活用し、
後から設定しだいで出す出さないで切り分けるのが良いかと思います。
public function execute()
{
Log::debug('処理開始');
if ( $obj->isTest() ) {
// 今は固定文字列ですが、周辺のObject情報を詰めても良さそう
Log::info( '条件に入りました。' );
return;
}
Log::debug('処理終了');
}