本記事では、テストコードをまだ書いたことのないプログラミング初学者向けに「今日からテストを書いてみようかな」と思ってもらえるよう、チュートリアル形式で簡単なテストの流れを説明します。題材はLaravelですが、他のフレームワークでも同じようなことはできると思います。注:本記事は、以前に私がQiitaに投稿したLaravel5.8のテストチュートリアルをLaravel6で動作するよう改訂したものです。6.4.x簡単な画面(HTTPレスポンス)のテストまずは、Laravelを触ったことのある人なら一度は見たことのある?Welcome画面をテストしてみます。これが正常に表示されることを、目視ではなくテストコードで確認してみましょう。Laravelをインストールすると、既にtests/Feature/ExampleTest.phpという、テストコードのサンプルが存在します。}}このExampleTestは、Tests\TestCaseを継承しており、テストに関する様々なメソッドが使えます。$this->get('/')で、'/'にアクセスした(GETリクエストした)結果のレスポンス(注1)が$responseに代入されます。正確には\Illuminate\Foundation\Testing\TestResponseが代入されます。OKであること)をチェックしています。ステータスコードについては以下を参考にしてください。MDNこのExampleTestを実行するには、Laravelのルートフォルダで以下コマンドを実行してください。./tests/Feature/ExampleTest.phpすると、以下の結果が表示されました。assertion)OK、と表示されています。OKだった)ということです。これをテストコードで確認することができました。https://shonansurvivors.booth.pm/items/3096761ビューのテストただ、このテストでわかったのは、正常にレスポンスが返ってきた、ということまでです。Welcome画面が表示されたのかどうかまでテストできていません。現状のルーティングを見ると、'/'へアクセスすると、'welcome'というビューが表示されることがわかります。view('welcome');});welcomeというビューは、具体的にはresources/views/welcome.blade.phpというビューのテンプレートです。このresources/views/welcome.blade.phpこそがあのWelcome画面なので、このテンプレートが使われているかどうかをテストで確認してみます。tests/Feature/ExampleTest.phpに以下のコードを追加します。追加}このようにassertViewIsメソッドで、どんなビューが使われたのかをテストすることができます。修正後のExampleTestを実行してみます。assertions)こちらも結果はOKとなりました。あのWelcome画面が表示されていることを、テストコードで確認することができました。assertSeeメソッドを使うと、表示(注2)されている文字列もテストできます。正確にはhtml内にその文字列が含まれているかをテストします。htmlのタグなども確認の対象になります。Welcome画面にLaravelの文字が表示されていることを、テストコードで確認してみましょう。tests/Feature/ExampleTest.phpに以下のコードを追加します。追加}修正後のExampleTestを実行してみます。assertions)こちらも結果はOKとなりました!ログイン中かどうかを絡めたテストここから先は、ユーザーがログイン中かそうでないかによって結果が異なる画面をテストしていきます。laravel/uiライブラリからユーザー登録画面やログイン画面等を作成できるので、これを実行します。dev上記コマンドの詳細については、以下の記事を参考にしてください。QiitaWelcome画面にユーザー登録画面とログイン画面へのリンクが追加されました。以下、テストではなく人力でユーザー登録画面にアクセスし、ユーザー登録を行なっています。ユーザー登録が完了すると、以下のホーム画面へ遷移します。ログイン画面からログインした場合も、このホーム画面へ遷移します。ホーム画面は、ログイン中の時のみ表示されます。ログインしていない状態で直接/homeへアクセスすると、ホーム画面は表示されず、ログイン画面へリダイレクトされます。この「ホーム画面は、ログイン中の時のみ表示される」ということをテストコードで確認してみましょう。make:authコマンドによって作成された、app\Http\Controlles\HomeControllerで行われています。このHomeControllerをテストするためのHomeControllerTestを作成します。以下コマンドを実行すると、テストの雛形を作成できます。HomeControllerTest作成されたテストの雛形の内容は、以下になります。}}このtests/Feature/HomeControllerTest.phpを以下の通り編集します。追加(ホーム画面で表示されているメッセージ)}このHomeControllerTestを、以下コマンドで実行します。./tests/Feature/HomeControllerTest.phpすると、以下の通り、OKではなくFAILURES!となりました。302.と出力されています。ログイン中でない状態でアクセスしたので、リダイレクトを示す302のステータスコードが返ってきた、ということです。MDNそこで、ログインした状態を作り出してテストしてみます。DBには、先ほど人力でユーザー登録画面にアクセスして登録したユーザーデータが存在するので、テストではこのユーザーを使うことにします。rows)tests/Feature/HomeControllerTest.phpを以下の通り編集します。}}actingAsメソッドで、そのユーザーとしてログイン済の状態になります。User::find(1)で、DBのusersテーブルからidが1であるユーザーを取ってきています。HomeControllerTestを、以下コマンドで実行します。./tests/Feature/ExampleTest.phpすると、OKとなりました。in!が、html中に存在することが確認できました。このようにログイン中かどうかが絡む機能も、テストコードで確認できます。テストに必要なDBのデータ準備もコードで自動化してみます。Laravelではテスト用のDBのデータを作るのに、ファクトリというものを使う方法があります。database/factories/UserFactory.phpが、ユーザーデータを作るためのファクトリです。];});このファクトリの詳細については本記事では触れませんが、これを使うといい感じにダミーのデータを作ってくれます。ファクトリについてもっと知りたい方は、以下記事を参考にしてください。Qiitaこのファクトリを使うよう、tests/Feature/HomeControllerTest.phpを以下の通り変更します。}}ファクトリで作成されたユーザーにて、ログイン中の状態を作っています。以下コマンドでHomeControllerTestを実行すると、結果はOKとなりました。assertions)ただ、これだとHomeControllerTest実行のたびにDBにダミーのユーザーデータが1件また1件...と作られてしまいます。rows)2件目がファクトリで作られたダミーのユーザーデータです。これに対しては、ひとつのやり方として、テスト用のDatabaseTransactionsを使うという方法があります。これを使うと、テストの実行後にDBをロールバックし、テスト実行中にDBに作ったデータが残らなくなります。tests/Feature/HomeControllerTest.phpで、DatabaseTransactionsを使うようにします。assertions)テスト終了後のDBを見ると、ユーザーデータはテスト開始前時点から増えてはいません(2件のまま)でした。rows)これでDBにダミーデータが残ることなく、何度でもテストを実行できます。最後に以上で、本記事のテスト体験ツアーは終了です。テストでどのようなことができるか、イメージはつかめたでしょうか。本記事をきっかけに、テストを書き始めていただければ幸いです。(1)関連リンクQiitaはてなブログをはじめよう!shonansurvivorsさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。