転職はじめに今年2019年1月からWeb系エンジニアへの転職活動を行っていましたが、このたびWeb系の自社開発企業(自社のWebサービス等を外注せず社員で内製開発・運営している企業)から内定をいただき、入社を決めました。現職は非IT系企業にてプログラミングを一切行わない仕事をしているのですが、担当するWebサービスや社内システムの改善が様々な事情・制約で思うようには進まない中、現状を少しでも変える為、また自己研鑽の目的で、昨年2018年5月から独学でプログラミング(Python)の勉強を開始しました。半年後の2018年11月、個人開発でWebサービスを完成させたことを機にそれまでのプログラミング勉強法をブログにまとめ、初めて作ったtwitterアカウントで告知をしたところ、はてなブックマークのホットエントリー入りするなどしました。プログラミングでのモノ作りそのものに加えて、その成果や学びをブログやtwitterで発信することの楽しさに目覚めた私は、GitHubやQiitaのアカウントも取得し、アウトプットを継続していきました。connpassに登録されている勉強会やもくもく会にも参加し、Web系エンジニアの方々との交流も開始しました。2018年12月:転職を意識し出した時期こうした活動を通じて、趣味や自己啓発ではなく本業としてWeb系エンジニアの世界に飛び込んでいきたいという思いが高まり、12月中旬ごろから転職の為の情報収集を開始しました。若くは無い年齢で家族を抱えながら実務未経験の職に転向するわけですので、上記の「好きが高じて」といった動機だけではなく、他にも現職への様々な思いや自身の将来への考えもある中での転職なのですが、それらも書くとあまりに長くなるので、ここでは割愛します。2019年1月:転職活動開始Wantedlyにプロフィールとポートフォリオを掲載の上、1月中旬からWeb系の自社開発企業に絞って面談を申し込みました(企業側から面談のお誘いを受けることもありました)。twitter上でも転職活動開始を宣言。これがきっかけで面談に繋がった企業も僅かながらありました。1月下旬には実際に企業との面談を開始しました。2019年2月:各社との面談〜選考面接〜内定2月は各社との面談、選考面接を順次行いました。中には技術面接を行う企業もありました(技術面接と銘打っていなくても、技術的な理解度を確認する質問が出る面接もありました)。最終面接を経て、2月の下旬ごろから内定が出始めました。内定を通知いただいた企業とは再度面談(オファー面談)を行いました。処遇に関しては内定通知書に記載されているので、実務未経験であった私の場合はそこはあまり話題にはせず、内定通知書には書かれていない、Web系エンジニアとしてスキルを伸ばせそうな環境であるかどうかを重視して改めて確認しました。当面はコードを書くことに専念させてもらえるか(現職でプロジェクトマネジメント経験があることから、その方面の仕事に最初からアサインされたりするようなことがないか)コードレビュー、テスト、CI/CD、Docker活用の取り組み状況それまでの面談や面接でも同種の質問はしてきたのですが、採否がかかっている面接の場よりも、内定を貰った後のオファー面談の場の方がやはり遠慮なく質問しやすいので、そこで自分が気になる点は納得行くまで確認させてもらいました。面談後は、現職の上司と退職に向けた調整を行い、退職日も定まった段階で転職先企業へ入社承諾の連絡をしました。これから2019年3月末を現職の最終出社日とし、4月は有給を消化、5月から転職先の企業へ入社する予定です。現職は10年近く働いたこともあり、社内や取引先に知り合いも多く、特に親しい人・お世話になった人には最終出社日までにできる限り会って、これまでのお礼も含め話をしておきたいと思っています(現在進行中)。4月の過ごし方はまだ計画中です。最後に昨年2018年5月の連休中、私は漠然と「プログラミングを学んで簡単なアプリ程度を作れるようになりたい」と思いながら、書店で初心者向けの本を手に取っていましたが、まさかその1年後にプログラミングを仕事にする職に就くことになるとまでは想像していませんでした。日々の行動を変えることが、自分の考えも変え、(ちょっと大げさな言い方ですが)人生も変えてしまうのだと実感しました。いずれにせよ、まだWeb系エンジニアとしてのキャリアのスタート地点に立ったばかりですので、これからも変わらずインプット・アウトプットを継続していきたいと思います。今回の転職活動を応援して下さった方々、本当にありがとうございました!そして2019年5月から予定通りWebエンジニアとして働き始めました。以降の話はこちらからどうぞ。本記事では、テストコードをまだ書いたことのないプログラミング初学者向けに「今日からテストを書いてみようかな」と思ってもらえるよう、チュートリアル形式で簡単なテストの流れを説明します。題材は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だった)ということです。これをテストコードで確認することができました。ビューのテストただ、このテストでわかったのは、正常にレスポンスが返ってきた、ということまでです。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にダミーデータが残ることなく、何度でもテストを実行できます。最後に以上で、本記事のテスト体験ツアーは終了です。テストでどのようなことができるか、イメージはつかめたでしょうか。本記事をきっかけに、テストを書き始めていただければ幸いです。Botを作ろう!」という教材をTechpitで公開し、約1ヶ月半が経過しました。多くの方に購入いただき、また教材への感想も多数いただいています。今回はそれらを紹介させていただきます。最後にTechpitでのレビューTechpitでは受講した方が任意でレビューを投稿することが可能で、教材のトップページにはそれらレビューが表示されます。現時点では、投稿された全てのレビューで5段階評価最高の星5をいただけています。以降は、実際のレビュー内容です。