テックエキスパート体験レビュー19日目です。前回の記事でお伝えした通り、現在金曜日までの簡易的なWEBサービス制作をやっているのですが、その中で「お、ちょっと成長したかな？」と感じた事がいくつかあります。
その変化を少しお伝えできればと思います。そしてそういった変化を感じるにつけ、「短期コースを選んでよかったな」ともひしひしと感じています。
変化①エラー文を見ても拒否反応が出ない
プログラムを書いていると必ずと言っていいほど何かしらのエラーに遭遇します。その時下図のようなエラー画面が表示されるのです。
テックエキスパートに通い始めた当初は、こんな画面を見るとすぐさま拒否反応が起きて全然エラー文も読めなかったのですが、最近では「おーどうした？」というくらいの感覚でエラー文に向き合えるようになりました。
そしてエラー文の内容を紐解き、どこに問題があるのか仮説を立て修正し、エラーを解決できるように気づいたらなっていました。
変化②他の人のコードを見てエラーの原因がわかる
またエラーの話ですが、プログラム書く時って自分で書いたコードなら比較的問題点なども分かりやすいですが、他人のコードってぱっと見よくわからなかったりします。
しかし最近気づいたのですが、他の人が書いたコードを見ても「何が原因で上手く動作できていないのか？」が何となく分かるようになっていました。
もちろんメンターのように何でも答えられる訳ではありませんが、おおよその検討はつける事ができるようになった点から「成長したなあ」と感じています。
プログラミングの挙動が掴めてきた
これは感覚的な話になってしまうので微妙なのですが、何となくプログラムの挙動が把握できるようになってきました。
挙動というのは例えば「ここにこう書くと、この順番に動いて、こことここがネストしてるからこう作用するだろうな」みたいな、コードとコードの関係性みたいなのが何となく掴めてきました。
何というか、「自分のペットが懐いてきたら何となく言いたい事が分かるようになった」みたいな事と同じ感じでしょうか。
とにかくコードの挙動のクセとか好みが何となくわかってきたのは、今後に向けて大きいような気がしています。
こんな感じで約20日間プログラミングに向き合い続けて、ようやく少しの成長を感じました。
短期か夜間か迷っていたけど短期にしてよかったと思う
テックエキスパートの入校の際に「夜間コースにするか」「短期コースにするか」迷っている方もいるかもしれません。
事実私は入校直前まで夜間コースで考えていたのですが、色々考えて短期コースに変更しました。
そんな「どっちのコースにするか問題」ですが、前述した「成長してきた感」を感じた時に、「あ、やっぱり短期にしてよかった」と思いました。
というのもこの「何となく挙動が分かってきた」みたいな感覚というのは、ある一定期間１つの事に没頭しないとなかなか掴めないと経験上考えているからです。
これは読者の方も実感値として何となく分かるかと思いますが、何事も「毎日少しずつ」触れるよりも「がっつり１つのlに没頭する」方が体に染み着きやすいですよね。
例えば夜間コースの場合は、１日のうちプログラミングに割ける時間というのはどうしても2時間前後くらいになってしまうのに対し、短期コースでは「1日10時間以上毎日」プログラミングに触れることになります。
そのためどちらかというと「短期」の方が心身ともにプログラミングに適応しやすくなってくるのかなと思っています。
ということで備忘録
ということでここからは備忘録です。現在テストコードの学習をしているのですが、これもjavascriptの次くらいに分からないですね、、。
コントローラーのテストコード
コントローラーのテストコードですが、これも前回の記事でやっていたモデルのテストコードと基本的には一緒な原理のようです。
参考記事：https://qiita.com/shizuma/items/84e07e558abd6593df15
基本形
・describeで「今からこれのてすとやるよ〜と宣言」
・２個目のdescribeで具体的な対象を示唆
・itで「テストしたいこと」を記載
・そのあとに仮でリクエストをしたことにするコードを書く
・予測される結果を書く
・で、コントローラーのテストでは1アクションに対し2以上のexampleが必要なので続けて書く。
＜例＞
describe post Controller do
describe 'GET #index' do
it "renders the index" do
get :index
expect()to.〜〜〜
end
it "テストしたいこと" do
"仮リクエスト"
"予測される結果を書く"
end
endちなみにexampleというのはdescribe〜endまでの１まとまりのことのようです。typeというのはmodelとかコントローラーとか何のテストしてるの？と言うことみたいです。responseというのはビューの情報を持つメソッドで、正しいビューが表示されているか否かを確認する際に使う
assignsメソッド
これは元となるアクションで定義しているインスタンス変数が合っているかどうかをテストするためのメソッド。
直前でリクエストしたアクション内で定義されているインスタンス変数をシンボル型でとる。（@uaserなら:userになる）
参考記事：https://www.c-and-d.org/rspec_controller/
create_list
これはcreateで複数データを作成した場合に用いる第一引数に作成したいインスタンスをシンボル型で取り、第二引数に数をとる。
ここの順番を変えるにはsortメソッドを使う。
tweet= create_list(:tweet,5)こんな感じで使います
ここまでの内容をまとめるとこんな感じでテストコードを書く事ができます。
describe 'GET #index' do
it "何かしら書く" do
posts = create_list(:post, 3)
get :index
expect(assigns(:posts※indexアクションで定義した変数)).to match(posts※ここで定義した変数)
end
it" "
end
endFakerというGEMでダミーデータを生成
fakerというgemを使うと、ダミーデータをいくつでも生成できるようになります。詳しい使い方は参考記事を参照ください。
参考記事：https://qiita.com/ginokinh/items/3f825326841dad6bd11e
場合分けをする際には「context」を使う
場合分けをしてテストをする場合は「context “内容” do」で場合分けを行う事ができます。
build(:インスタンス名）でインスタンス生成
buildメソッドは「カラム名：値」で引数を渡す事でファクトリーで指定したデフォルト値を更新可能。
post= build(:post, name:nil)ちなみにattributes_forというのもあります。buildはオブジェクトを生成するのに対しattributesはハッシュを生成するようです。
参考記事；https://codeday.me/jp/qa/20190121/169078.html
letメソッド
letメソッドはテストの中で変数を定義する時に使う。機能的にはただ変数を定義するものだが「遅延評価」といって、呼び出された時にはじめて動くのが特徴。
これにより読み取りに時間がかからなかったりするメリットがある。
let(:変数名) {中身 create(:group)など}参考記事；https://forest-valley17.hatenablog.com/entry/2018/10/14/205550
統合テストはフィーチャスペックで
何だかよく分からないですが、統合テストでは「フィーチャスペック」というのを書いてテストを行うようです。
フィーチャスペックの利用にはCapybaraというGEMの追加が必要ですが割愛します。フィーチャスペックで書く場合は、単体テストで使ってきた文言が以下のように変わります。
it▶︎scenario
before▶︎background
describe▶︎feature
let▶︎given
など
visitメソッド
引数にURLまたはプレフィックスを入れて、そのページに移動できるメソッド
visit("/post")click_onメソッド
その名の通りクリックするメソッド
click_on("post")
ポストという要素をクリックfill_inメソッド
fill_inで値が入力される動きを作成可能
その他諸々まとめられています
この他にも色々とあるのですが、Qiitaにとても良い記事があったので取り上げさせていただきます。
参考記事：使えるRSpec入門・その4「どんなブラウザ操作も自由自在！逆引きCapybara大辞典」
