■

非同期通信(Ajax)

JSON

データ交換を行う為のデータ記述形式

キーとバリューの組み合わせでデータを表現

htmlをレスポンスとして受け取るとブラウザは全てのhtmlを書き換える

AjaxではJSON形式でレスポンス

ブラウザの一部のみを変更可能となる

デフォルトアクション

htmlの要素を操作した際に定められている挙動

リクエスト「JSON形式で返してね」

コントローラー「アクションで用意しておくよ」

ビュー

非同期は同期同様にviewフォルダの中にJSON形式のファイルを準備

○○.json.jbuilder

Railsには、1つのコントローラのアクションの中でHTMLとJSONといったフォーマット毎に条件分岐できる仕組みがある

テストの備忘録⑤

コントローラーのテスト

 コントローラー内のメソッドであるアクションが呼ばれた際の挙動をチェック

Gemfile内でgem 'rails-contoroller-testing'でインストール

specディレクトリ直下にcontrollersディレクトリを作成し、その中にテストコードを書くファイルを作成

ファイルの先頭にrequire 'rails-helper'を追記

擬似的になリクエストを行うコード

httpメソッドにそれぞれ対応するメソッド(get,post,delete,patch)を利用する。

(引数として、利用したいコントローラーのアクションをシンボル型で渡す。必要なパラメーターがある時は、ハッシュ形式で渡す。)

response

example内でリクエストが行われた後の遷移先のビューの情報を持つインスタンス

render_template

マッチャの一つ。引数で指定したアクションがリクエストされた時に自動的に遷移するビューを返す。

アクション内で定義されているインスタンスが期待したものかテストする

editなどレコードが入ってないといけないアクションのテストを行うにはfactory_botでレコードを保存する 

assignsメソッド

コントローラーのテスト時、アクションで定義しているインスタンス変数をテストするためのメソッド。

*_listメソッド

factory_botの設定ファイルに存在しているデータを複数作成したい場合に利用

Faker

email,電話番号,名前などのダミーデータを作成する為のGem

factory_botの設定ファイルの中でFakerメソッドにてランダムにダミーデータを作成する。

matchマッチャ

引数に配列クラスのインスタンスをとり、expectの引数と比較するマッチャ。

配列の中身の順番までチェックする。

テストについての備忘録④

今回はfactory_botについてまとめたいと思います。

factory_botとは

ダミーのインスタンスを作成する事ができるGem

specディレクトリの直下にfactoriesディレクトリを追加し、さらに、その中にデータ作成のためのテンプレートを用意し、各クラスのインスタンスに定めるプロパティを設定しておく事で、簡単にインスタンスを作成したり、DBに保存できるようになる。

データの作成をするメソッド

クラス名のインスタンスをシンボル型で引数にする。

buildメソッド

DB保存はしないがアソシエーションは保存する。

クラス名.new = FactoryBot.build

createメソッド

DBに保存された状態でデータ生成。

factory_botはrails_helper.rb

RSpec.configure do |confid|~endの間に

config.include Factory::Syntax::Methodsを追加する事でFactoryBotを省略する事ができる。

テストについての備忘録③

テストについてのまとめ第３回目です。

マッチャとは

エクスペクテーションの中で、テストが成功する条件を示す。

期待値と実際の値を比較して、一致したor一致しなかったという結果を返すオブジェクト

expect(...).to xxxのtoの直後に出てくるxxxの部分

(toはマッチャではなくマッチャの実行結果からテストをパスさせるかどうかを判断するRSpecメソッド)

よく使うメソッド

<eq>

期待値と実際の値が等しいかどうか検証

<be_xxx>

「?」で終わり、戻り値がtrue/falseになるメソッドをbe_xxxのような形で検証

<change + from/to/by>

expect{X}.to change{Y}.from(A).to(B)→「XするとYがAからBに変わる事を期待する」

「by」を使うと１個減るまたは増える事を検証

<配列+include>

配列に〜が含まれている事を検証

<valid>

バリデーションされているか検証

be_validで全てのバリデーションをクリアするか検証

なお、今回の記事は下記のブログを参考にさせて頂きました。

 

使えるRSpec入門・その2「使用頻度の高いマッチャを使いこなす」

https://qiita.com/jnchito/items/2e79a1abe7cd8214caa5

テストについての備忘録②

前回の続きでテストコードに関するまとめを書いていきたいと思います。

<describe>

テストをグループ化を宣言。

doとの間のメソッド名には"#"をつける。

何についての仕様なのかを記述

ネストする事ができる。

<context>

テストの内容を条件・状況ごとに分類するグループ化宣言する。

< it >

期待する動作と動作を記述し、テストをexampleにまとめる役割。

exampleは実際に動作するテストコードのまとまりのこと。

<before>

共通の処理をまとめる事でDRYの効果がある。

describeやcontextの中に記述する事でbeforeブロック内の内容が実行される。

<エクスペクテーション>

実際にテストする式のこと。

it do ~ endの間に記述する。

expect(X).to eq Yで記述(to eqの部分はマッチャと呼ばれる機能)

describeとcontextはテストを分類に関する処理

itとbeforeはテストの実行に関する処理

テストについての備忘録①

テストについて、理解がよく無いのでブログにまとめることで知識を定着させていきたいと思います。

RSpec

Rubyを元にしたテストのドメイン特化言語。

Spec = 「仕様書」であり、要求仕様をドキュメントに書く感覚。

ドメイン特化言語

特定の作業の遂行や問題の解決に特化して設計された言語。

RspecのGemのインストール

Gemfileにて"gem 'rspec-rails'"と追記

インストール後Rspecの設定ファイル作成

ターミナルにて rails g rspec:install

設定ファイルを作成すると「rails_helper.rb」と「spec_helper.rb」が作成される

rails_helper.rb

rails特有の設定を書くためのファイル

rails_helper.rbでは既にspec_helper.rbが呼ばれている

spec_helper.rb

全体的な設定を書くためのファイル

Ruby単体で使用する

RSpecで書いたテストコードはターミナルから「bundle exec rspec」と打つことで自動的に実行される

Gitについて今分かっていることをまとめてみた

アウトプットはTwitterのみで、しばらくブログを書いておりませんでした。

しかし、カリキュラムも応用に入りますと、内容も難しくTwitterだけでは物足りないと思い始め、ブログを再開することにしました。

最近はGitを使うようになりましたが、どうにも内容がややこしく感じるので、一度アウトプットすることで整理したいと思います。

 Gitとは

ソースコードなどの変更履歴をバージョンとして記録し管理するシステムのこと。

作業者が複数人いてもファイルの並行して扱えるような仕組み。

Gitの仕組みを利用したWebサービスをGitHubという。

インデックス

バージョンを記録するためにファイルを一時的に登録する場所。

git addでインデックスに追加。

コミット

管理対象となるファイルをその瞬間の状態で記録する。

コミットメッセージでどのような変更を行ったかメモを残すことができる。

リポジトリ

コミットを貯めていく場所。

ローカルリポジトリ(ローカル環境)とリモートリポジトリ(ネットワーク上)がある。

ブランチ

リポジトリで管理している履歴を枝分かれして並行作業する際に役立つ機能。

プッシュ

リモートリポジトリにローカルリポジトリと同じ内容のブランチが作成される。

プル

リモートリポジトリからローカルリポジトリを更新する操作。

GItの操作はまだ少し怖さがありますが、怖さをなくすには使い続けて慣れていくしかないだろうなと思います。