■
お疲れ様です!
では今日はテストコードの手順的なのを作業でやった順番で記述していこうと思います!
まずitでグループ分けされた中に個別で記載していきます。
一旦ここまで記述したらテストコードを実行します。グループ分けした状態でも実行は可能。実行するときは、bundle execコマンドに続けて、rspecコマンドを入力してファイルを指定後に実行します。
確認後実際に内容を記述していきます。
例えばnicknameが空だと保存できないというテストコードの場合
nicknameの値が空のインスタンスを生成します。
この後、正常に機能するか検証するため、バリデーションを実行します。ただ、バリデーションは実際にデータが保存される前しか実行されないのでvalid?を使用して任意のタイミングで実行させてエラーがあるかを判断させます。
先程生成したインスタンスに対してバリデーションを実行するように記述します。
上記のような「想定した挙動」と「アプリの実際の挙動」を確認します。
この確認をテストコードに落とし込んだものをexpectationといい、expect().to matcher()を雛形に、テストの内容に応じて引数やmatcherを変えて記述します。
今回はexpectの引数にuser.errors.full_messagesと記述し、インスタンスのエラーメッセージを指定し、includeの引数には想定するエラーメッセージを記述を適切に行いました。
ここでテストコードを実行して成功すれば完了です。
この後の流れは大体一緒でitにそれぞれのテストコードを記述していきます。
以上が最初に学習した時の内容です。
その後何回か練習をした後に効率的にコードを書くためにGemを導入しました。
まず最初にFactoryBotを導入しました。
これはインスタンスをまとめることができるGemで、別のファイルであらかじめ各クラスのインスタンスに定める値を設定しておき各テストコードで使用できると言ったものです。
実際にユーザーの情報を保存する場合は様々な情報があるので毎回コードを書くとかなり冗長になり、また可読性も落ちます。
導入後他のテストコードもかなり記述を短縮できたので見やすく感じました。
また、共通した記述も可読性にかけてしまうので切り出しました。
beforeを使用してインスタンス変数に保存情報を格納数ことでかなりスッキリします。
次に、FactoryBotで設定した値は固定されてしまうのでメールアドレスなど一意性のあるものに関しては別の値を使用したいのでランダムに値を生成してくれるFakerというGemを導入しました。
様々な意図に応じたランダムな値を生成してくれます。
実際にはFactoryBotで作成したファイルに記述していきます。
これでテストコードはかなり効率化されたかと思います。
初めてテストコード記述する時にまず、イグザンプルの洗い出しに時間がかかったなと感じました。
これはプログラミング言語を始めてよく思うことですが技術も必要だけど問題や課題の洗い出しことや考える力もとても重要だなと感じました。
特に要件定義などやったときは何があればいいんだろうとか色々考えていたのでこれからはそういった能力もレベルアップできるように読書や情報収集などできることは継続していきたいなと思います!!
ではまた!
■
お疲れ様です!
昨日は学んだことの復習を少し行いました!
テストコードについてです。
テストコードとはアプリケーションの挙動を確認するためのコードです。
テストコードを書く際は、RSpec(アールスペック)というRuby on Railsのテストコードを書くためのGemを用います。また、テストコードにはパターンがあり正常系と異常系に分かれます。
正常系はユーザーが開発者の意図する操作を行った時の挙動を確認するもので、異常系はその逆でユーザーが開発者の意図しない操作を行った時の挙動を確認するものになります。
また、テストコードには単体テストコードと結合テストコードの大きく分けて2種類あり、単体テストコードではモデルやコントローラーなどの機能ごとに問題がないかを確認することができます。
結合テストコードでは、ユーザーがブラウザで操作する一連の流れを再現して、問題がないか確かめます。
作業の流れとしてはまずはGemをアプリケーションに導入し、.rspecに設定を追加します。
rails g rspec:model テストしたいモデル名
を実行してテストファイルを生成します。
また、生成されたファイルの1行目にrails_helperという記述がありますがこれは機能テストをする際に、共通の設定を書いておくファイルです。各テスト用ファイルでspec/rails_helper.rbを読み込むことで、共通の設定やメソッドを適用します。
テストコードについて先の用語のアウトプットを先にして次回から本格的に手順をアウトプットしようと思います。
describe(ディスクライブ)
テストコードのグループ分けを行うメソッドです。どの機能に対してのテストを行うかをグループ分けして、その中に各テストコードを記述していきます。
do~endの中でさらに入れ子構造を取ることもできます。
it
itメソッドはdescribe(ディスクライブ)メソッド同様にグループ分けを行うメソッドです。itの場合はより詳細に、describeメソッドに記述した機能において、どのような状況のテストを行うかを明記します。また、itメソッドで分けたグループをexampleとも呼びます。
example(イグザンプル)
itで分けたグループまたは、内容のことを指す場合もあります。
以上のものを記述してどの機能に対するテストコードなのかを記述していきます。
これはテストコードを実際にやってみた時の感想ですがこの時かなりエラー文が読めるようになった気がしました。
前に話した写真投稿型アプリケーションでテストコードを記述したおかげで機能の把握がしやすくまたターミナルに毎回と言っていい程エラーが表示されていたのでエラーを体験する機会が増えて数日前よりかは、かなり成長を実感したのを覚えています。
プログラミングは挫折する方が多いと聞くので逆にエラーなど起きたら喜んで解決のためのアクションをして一つでも多く自分の知識として吸収できたらいいと考えています。
ではまた!
■
お疲れ様です!
学習していると今週もあっという間に終わってしましました!
今日は、一緒に学習してきた仲間のアプリなどを今日は拝見する機会がありました。
はっきりいって自分が一つの機能につまずいている間に皆さんフロントに力入れたりだとかでシンプルにすごいなと言うのが感想でした。
ただ、同じ学習をした仲間であり、ある意味ライバルでもあるのでライバルがしっかりと作り込んできているのを目の当たりにすると燃えてきますね!!
エラーにずっとハマってしまっていて少しモチベーションも微妙なのでとりあえず岩盤浴でもいこうかと思います。
ちなみに今他にもアプリ制作しながら学びたいことがあるので一旦今作成しているアプリは保留にしようかなと思っています。
あと明日からまた復習内容多めで投稿もしようと思います。
とりあえず覚えていないことはもちろんですけど今までやってきたことを思い出しながらコード記述することでより一層プログラミングの知識を身につけていきたいなと感じました。
なので今日は学習ってよりかは感想とか思ったことになってしまいましたが今後もよろしくお願いします!
復習内容のアウトプット
お疲れ様です。
今日は昨日の復習の続き書いていこうと思います。
昨日はdeviseというgemを使ってユーザー管理機能を作りました。
今日はそのユーザーと投稿を紐付け用と思います。
この時に投稿情報にユーザー情報を載せると投稿を呼び出すたびにユーザー情報にもアクセスしてしまうN+1問題と言うものが発生してしまいます。
これを解決するためにincludesメソッドを使用します。
呼び出す際に
モデル名.includes(:紐ずくモデル名)
といった感じで記述することで上記のN+1問題を解消することができます。
といった感じでアプリの方を開発しました。
自分ではコードを打ち込んで理解しているつもりでもスペルミスでエラーを起こしたり、新しい知識を詰め込みすぎて覚えきれていない部分もありますが記憶の片隅にこんな機能あったなとか若干でも使い方を覚えることで調べて解決できるのでこれを反復して少しずつ自分の技術にしていきたいと思います!
あ、そろそろ証明写真も取らなければ!
週末には髪の毛も切るので心機一転転職活動に励もう!
少し学習時間も減ってしまいますがこれからも自分の将来のために頑張りたいと思います!
ではまた!
今日の作業内容
お疲れ様です!
今日のオリジナルアプリですが若干のフロントの編集とデプロイを行いました!
デプロイを行って色々と機能を確認していると地図機能で地図が読み込まれないというエラーに...。
こんな感じです。
どうしたもんかと公式ドキュメントを調べながら確認していくけど全然解決できない。
APIは有効になってるしプロジェクトも結びついている。アカウントにもクレジットは登録されているのに...。
ただ一つわかるのは多分読み込みが甘い!!
他のサイト確認しても同じような情報ばかりなのでやはり公式ドキュメントをみまくろう!
といった感じで作業していました。
ただ転職活動の準備も動かなければならないのであまり力を向けられないのが本音です。
とりあえず転職活動を大優先して隙間時間で開発を続けるしかないなーと思います。
とりあえずまた明日復習した学習内容と作業内容を残していこうかと思います!!
写真投稿アプリの作成過程(続き)
お疲れ様です!
今日は機能のアプリ作成の後半の話を載せようと思います!
昨日は知識として学んだバリデーションを使って保存するデータに制約を設けました。
また、今回はアクションが増えるということでまずdestroyアクションをルーティングとコントローラー内に記述しました。
ビューにも削除用のボタンを設けたのでlink toにrails routesで確認したパスを記載します。
次に編集です。
editで編集してupdateで更新します。流れはnewアクションとcreateアクションに似ていますが、異なる点は編集から更新の場合はすでに存在しているレコードを洗濯して中身を置き換える点です。なのでeditアクションでは編集したいレコードをインスタンス変数に代入してビューに受け渡すことで編集画面が利用できるようになります。
7つのアクションでは最後になりましたがshowアクションである詳細ページ表示機能を実装します。
流れは今までと同じでルーティング、コントローラー、モデル、ビューの作成をします。
ここでコントローラーを確認すると違うアクションでも中身の記述が同じものがいくつかありました。
これは、複数人で作業する際など可読性にかけてしまうので今回はbefore_actionを使って特定のアクションにのみ実行される前に共通の処理を行えるようにしました。
これで投稿機能に関する部分が完了しました。
次は、ユーザー管理機能の実装をします。
ここで初めてユーザー機能について触れました。ユーザー管理機能と聞くとかなり難しいイメージはありましたが今回というか現在もdeviseというgemを使って実装しています。deviseはユーザー管理機能を簡単に実装できるgemのことです。
gemfileにgem 'devise'と記述後にターミナルでbundle installと記述しインストールしてから使用します。また、rails g devise:installと打つと設定用のファイルも作成してくれるというめちゃくちゃ便利笑
モデル作成も専用のコマンドがあってモデルやマイグレーションファイル、ルーティングの記述まで自動で行ってくれます。
マイグレーションファイルには自動でemailとpasswordが記述されるので他に追加したいカラムがあれば記述してマイグレートすれば完了です。
また、deviseに関してですがdeviseの処理を行うコントローラーはgem内に記述されているため、編集することができません。
なのでストロングパラメーターを記述する際は全てのコントローラーが継承しているappliction_controller.rbに処理を記述することで全てのコントローラーで共通となる処理を可能にできます。
また、ユーザーのログイン状況によってボタンの表示が変わるように実装しました。
user_signed_in?メソッドです。deviseが導入されている時に使用できます。
ユーザーがログインしていればTrueを、していなければFalseを返します。
if文で条件式として記述し実装しました。
それとログインしていない状態ではログインもしくは新規登録ページにリダイレクトされるようにredirect_toメソッドを使用して実装しました。
今回も少し長くなってしまったので次回に続きを記載していきたいと思います。
今日はオリジナルアプリをデプロイしたら急に地図が表示できなくなってしまったのでそちらの解決を行いたいのと要件定義(README.md)の編集を今日中に終わらせたいなと思っています!
ではまた!
オリジナルアプリの作業状況
お疲れ様です!
今日はREADME.mdにアプリケーションの機能などを追加で記述していました。
ある程度記述後は地図機能の実装です!
あと、もう一歩でルート検索機能が実装できそうなんですが中々うまくいきません!
今まで教材上で学んできたことってわかりやすかったなと感じます。
自分から新しい技術を学びにいこうとするとかなり難しく感じます!
特に今google maps apiを使ってアプリの方を実装していますがとりあえず公式ドキュメントを読み進めながら作業してきましたが地図の表示と検索後該当箇所にピンを立てるだけでかなり時間がかかってしまいました。
とりあえずjavascriptのコードが少しあやふやで常にググりながらコードを打つ感じになってしまっているのでできるだけ早めに復習してブログの方に残そうと思います。
とりあえず今日はもう少し作業してから転職活動の準備に移ろうと思います。
最後に最近知ったことですが僕の幼馴染も実はプログラミング学習をしていたそうなので今まで以上に仲間意識が出た気がします。
ではまた!!