【各章まとめ】Everyday Rails - RSpecによるRailsテスト入門 - 第7章 リクエストスペック
Everyday Rails 「RSpecによるRailsテスト入門 - 第7章 リクエストスペック」の復習用まとめ。
letなどは第7章でまだ出てきていないため、DRYではない箇所多数。
GETリクエストのテスト
リクエストスペックの作成
bin/rails g rspec:request projects_api
ファイル名称を変更する
自動生成される spec/requests/projects_apis_spec.rb だとおかしいので、projects_api_spec.rb に変更
テスト実装
RSpec.describe "Projects API", type: :request do it "loads a project" do user = FactoryBot.create(:user) FactoryBot.create(:project, name: "My Project", owner: user) FactoryBot.create(:project, name: "Other user Project") # index アクションのテスト get api_projects_path, params: { user_email: user.email, user_token: user.authentication_token } expect(response).to have_http_status(:success) json = JSON.parse(response.body) expect(json.length).to eq 1 # show アクションのテスト project_id = json[0]["id"] get api_project_path(project_id), params: { user_email: user.email, user_token: user.authentication_token } expect(response).to have_http_status(:success) json = JSON.parse(response.body) expect(json["name"]).to eq "My Project" end end
POSTリクエストのテスト
RSpec.describe "Projects API", type: :request do # index、showのテストは略 it "create a project" do user = FactoryBot.create(:user) project_params = FactoryBot.attributes_for(:project, owner: user) expect do post api_projects_path, params: { user_email: user.email, user_token: user.authentication_token, project: project_params } end.to change(user.projects, :count).by(1) expect(response).to have_http_status(:success) end end
コントローラスペックをリクエストスペックで置き換える
indexのテスト
RSpec.describe "Home Page", type: :request do it "responds successfully" do get root_path # ここはいい感じに読み替える expect(response).to be_success expect(response).to have_http_status "200" end end
createのテスト
- 基本的にコントローラスペックとほぼ同一。
- POSTリクエストの送信方法が post :create から post projects_path と名前付きに変わる。
- Deviceで認証制御している場合は、request spec内で認証用メソッドを呼ぶ設定が必要。
require 'rails_helper' RSpec.describe "Projects", type: :request do describe "#create" do context "ログインしている場合" do let(:user) { FactoryBot.create(:user) } context "有効な属性値の場合" do let(:project_params) { FactoryBot.attributes_for(:project) } it "プロジェクトを追加できる" do sign_in user expect { post projects_path, params: { project: project_params } }.to change(user.projects, :count).by(1) end end context "無効な属性値の場合" do let(:invalid_project_params) { FactoryBot.attributes_for(:project, :invalid) } it "プロジェクトを追加できない" do sign_in user expect { post projects_path, params: { project: invalid_project_params } }.not_to change(user.projects, :count) end end end context "ログインしているが、プロジェクトのオーナーではない場合" do # ... end context "ログインしていない場合" do # ... end end end
request spec内で認証用メソッドを呼ぶ設定をしないとダメ。
公式、もしくは書籍参照。everyday Railsでは簡単な方ではなく、詳細な方の設定をしている。
How To: sign in and out a user in Request type specs (specs tagged with type: :request) · plataformatec/devise Wiki · GitHub
念のためここにも記述。
spec/support/request_spec_helper.rbを作成
module RequestSpecHelper include Warden::Test::Helpers def self.included(base) base.before(:each) { Warden.test_mode! } base.after(:each) { Warden.test_reset! } end def sign_in(resource) login_as(resource, scope: warden_scope(resource)) end def sign_out(resource) logout(warden_scope(resource)) end private def warden_scope(resource) resource.class.name.underscore.to_sym end end
rails_helper.rb
RSpec.configure do |config| # ... # Use Devise helpers in tests config.include Devise::Test::ControllerHelpers, type: :controller config.include RequestSpecHelper, type: :request # ←こいつを追加する end
RSpecでフィーチャースペックを行う
事前準備
gemのインストール
group:test do gem 'capybara', '~> 2.15.2' end
spec/rails_helper.rbにCapybaraの設定を追加
# This file is copied to spec/ when you run 'rails generate rspec:install' require 'spec_helper' ENV['RAILS_ENV'] ||= 'test' require File.expand_path('../../config/environment', __FILE__) # Prevent database truncation if the environment is production abort("The Rails environment is running in production mode!") if Rails.env.production? require 'rspec/rails' # Add additional requires below this line. Rails is not loaded until this point! require'capybara/rspec' # この1行を追加
フィーチャーテストの実施
スペックファイルの作成
rails g rpsec:feature projects
テスト実装
require 'rails_helper' RSpec.feature "Projects", type: :feature do scenario "user create a new project" do user = FactoryBot.create(:user) visit root_path click_link "Sign in" fill_in "Email", with: user.email fill_in "Password", with: user.password click_button "Log in" expect do click_link "New Project" fill_in "Name", with: "Test Project" fill_in "Description", with: "Trying out Capybara" click_button "Create Project" expect(page).to have_content "Project was successfully created." expect(page).to have_content "Test Project" expect(page).to have_content "Owner: #{user.name}" end.to change(user.projects, :count).by(1) end end
Linux - 権限設定の確認や変更方法
下記のQiita
忘却曲線に基づいた効率の良い復習方法
忘却曲線とは?
ある事柄を記憶した後、時間をおいたらどの程度思い出せるか(厳密には思い出すのに必要な時間)、についての実験結果を図示したもの
出典: 忘却曲線 - Wikipedia
上記の図を見ると、1度も復習しない場合はわずか6日で学んだことの大部分を忘れ、逆に復習するした場合は忘れにくくなり、長期記憶となっていくことが分かります。
効果的な復習間隔
よく言われるのは、1日、3日、1週間、2週間、1ヶ月、3ヶ月。復習の頻度が少なかったり、回数が少ないと記憶が定着せず、理解が浅いままとなる。忘却曲線をベースに、復習の方法、回数、間隔を自分なりにアレンジする。学ぶ内容や難易度により変える。
例えば、3回復習したがあまり理解していない場合、次に2週間あけて復習してもあまり意味はない。もう少し復習の間隔を短くしたり、何度も復習しても理解できない場合は学ぶ教材の難易度を下げることなどが必要。また、3ヶ月後に同一教材をもう一度復習するというよりも、試験や模擬試験を受験し理解が浅い部分や抜け漏れがあった部分を補強するなど、学習方法を工夫するのが良い。仕事で必要な知識を素早く学ぶなら、帰宅後や休日に1~2回読み込み、仕事を通してアウトプット、理解が浅い部分を補強しながら身に付けるなど臨機応変に。
忘却曲線から見る間違った勉強方法
復習しない
忘却曲線から分かるように1~2週間経てば全部忘れます。
復習の間隔が長すぎる
1~2回目の復習では記憶の定着がまだ浅いため、復習しないと忘れる割合が高いです。1回目の復習は3日以内、2回目の復習は1回目の復習から1週間以内にすべきでしょう。復習の間隔が長すぎた場合、初回学習と同様の効果しか得られず記憶が定着しにくいため、効率が悪いです。
復習の回数が少ない
忘却曲線を見ると、1回の復習ではまだ記憶が定着しておらず、3回目からある程度定着してくることが見て取れます。「何度も繰り返す」ことを意識しましょう。
1回の勉強にじっくり時間を掛ける
漢字や英単語を覚えるために、一度に20~30回書いて覚えるなどが該当します。時間の無駄となる場合が多いので止め、適切な間隔を入れて繰り返しましょう。適切な間隔で復習することで記憶が定着し、理解も深まります。そのため、一度に20~30回書くのではなく、2~3回見る、書く、聞く、発音するのを間隔を空けて繰り返した方が学習効果が高いです。
繰り返しの復習で高い成果を出している例
学習方法の具体例がリンク先の記事です。繰り返し復習することで下記を実現しています。何回繰り返すのか?、毎回の復習で意識することは何か?等々の参考になる部分が多いため、オススメです。
東大入学後は、3年次にたった1年の準備期間で司法試験に一発合格。国家公務員第I種(当時)試験もクリア。卒業までに必要な162単位でオール「優」を取得。法学部における成績優秀者として「東大総長賞」を受賞し、同学部を首席で卒業している。
教科書を7回読むだけで、断然トップになれた!(前編) | プレジデントオンライン
教科書を7回読むだけで、断然トップになれた!(後編) | プレジデントオンライン
ポイントは
- 復習含め、7回繰り返し学習する。
- 復習間隔は忘却曲線でよく言われている間隔とだいぶ違い、アレンジが大きい。
- 1~7回目それぞれで意識することが違う。例えば、1回目は理解しようとせず全体像を把握するだけ。
1回目を読むとき、何より大切なのは内容を理解しようとしないこと。最初から丁寧に読んで理解しなければと考えると、「大きなストレスになるから」
3回目までは、あくまで「土台づくり」。だから、全体の理解度は2割程度らしい。
このように、1日、3日、1週間、2週間、1ヶ月、3ヶ月という復習間隔に囚われず、学びながら自分にしっくりくる学習方法に向けて改良しましょう。
【レビュー・体験談】【TechAcademy】2ヶ月間、Webアプリケーションコースを学んでみて
少し前ですが2017年の終わりから2018年のはじめに、TechacademyのWebアプリケーションコースで2ヶ月間学びました。コースで学んだ内容や個人的感想を書いたので、プログラミングスクール選びの参考にしていただければ。
受講したコース
TechAcademyの Webアプリケーションコース
受講した目的
SIer的な企業で働いており実装機会が少なくなったこと、また古い技術で開発しているため危機感を覚え、Railsを習得しWebエンジニアにスキルチェンジして転職したかったためです。
スクールをTechAcademyにした理由は、当時他のプログラミングスクールではなかった、最終課題に自分で考えたWebサービスを開発すること、その成果を持って転職活動をしたかったことが大きく、TechAcademyに決めました。
その後の転職活動において、「スクールに行って、独自のWebアプリを開発したこと」は一定以上評価して貰えた印象があったので良かったかなと思います。
受講時のスキル
- HTML、CSS、JavaScript、RubyをProgateとドットインストールで学習した
- Javaを用いた実装に複数年携わっており、プログラミング経験はあった
上記の感じで、正直、Web開発に関する技術はかなり低い状態での受講となりました。働きながらでの受講だったため、時間を確保するのに苦労したのが良い思い出です。
コースの内容
コースの具体的な内容は下記の通りです。
- HTTPなどのインターネットの仕組み
- HTMLとCSS(Bootstrap含む)の基礎
- ターミナルコマンドの基礎
- RubyとMySQLの基礎と簡単なWebアプリの作成
- GitとGithub
- Heroku
- Railsアプリを3つ
- 最終課題に独自サービスの開発
上記を見ると、Web開発に必要な基礎知識の習得から始まり、プログラミング言語であるRubyとデータベースのMySQLを丁寧に学びながら、最終的にフレームワークであるRailsをがっつり使いながら開発していく流れになっています。
要は、極力挫折しにくい学習順序になっており、RailsチュートリアルのようにHTML、CSS、Rubyとかは既に学習済みであることを前提とはしていません。
いわゆる全く知識ゼロの状態でも、全てをこなすことで最終的にRailsを用いてオリジナルサービスの開発が行えるレベルに到達します。とはいえ事前準備して望んだ方が効率的ですが。それについては後述します。
私は参加時にはWebアプリケーションを独自で開発するなんて想像もしていませんでしたが、2~3ヶ月後には下記を作れるまでにはなりました。
https://wow-together.herokuapp.com/
受講して良かった点
転職活動時に、自分で開発したWebサービスをアピールできた
受講目的でもあった、「転職活動時にWeb開発の成果を持って面接に望めた」点が一番でかいです。コースの中で複数のRailsアプリケーションを開発するため、最初は難易度の高さに驚きますが、復習を繰り返していると「あぁこうすればRailsでWebサービスが開発できるのか」ということが肌で理解できるようになってきます。
その結果、最終課題であるオリジナルサービスの開発もスムーズに進み、成果を持って転職活動を行うことができました。そもそもRailsで開発をしたことがない状態でWebエンジニアを目指して転職活動をしても、向いているか、できるかどうかも分からず自信が持てなかったと思います。
メンター制度のお陰で、学習ペースを緩めずに完走できた
TechAcademyの大きな特徴としてはメンター制度があり、週に1~2回ほどスカイプで直接質問をしたり、進捗状況を確認する場があります。これは質問の場が必ず確保できるという点でもメリットがありますが、一番大きかったのは、ちゃんとやらないとメンターから檄を飛ばされるという謎のプレッシャーでした。これがあるお陰で、終電で帰って来た時にもヤバイやらなきゃ!という思考回路が働き、長期に渡って、気が緩むことなく課題を前に進めることができたため良かったです。
やはり誰もチェックしていない完全独学状態では、終電で帰って来たら疲れたから明日やるか...となりがちです。ライザップやコナミスポーツなどのパーソナルトレーナーも、見てくれている人がいる、チェックされている状況である、ということが最後までやり切る原動力の一つになっている気がします。
とは言え終電連続であまり課題が進まない時に、全然進んでないねと言われた時の苛立ちは異常。逆にそのイライラを課題にぶつけてドンドン前に進めたので良かったですが、瞬間的に中々イラっとしたのは覚えています(笑)
Railsアプリを数多く開発する機会があり、Railsそのものに慣れた
コース全体を通して、全部で5つのWebアプリを開発します。Railsを用いないRubyとMySQLで作る簡易的なアプリ、Railsを用いた課題アプリ3つ、最終課題のオリジナルサービスの5つです。多くのアプリを開発することでRailsそのものに慣れた結果、独自開発をする際や既存サービスのキャッチアップをする際などにそれほど苦労せずスムーズに行えるようになりました。
これだけRubyやRailsで多くのアプリを開発する機会はスクールでないと得られません。Railsチュートリアルだと基本的に1つのアプリケーションしか作成しないため、Railsで開発するという勘所が掴みにくいです。
また、Railsチュートリアルをサポートする動画やスクールが増えてきましたが、正直Railsチュートリアルだったら無料で公開されており、自分でできるのでお金を払う意味を感じません。それだったら、Railsチュートリアル以外の開発機会が得られる他のスクールにお金を払った方が費用対効果が高いです。
ここがイマイチだと思った点
卒業後の技術の伸ばし方に関する情報が少ない
TechAcademy終了後、バリバリWeb開発ができるようになるかというと全然そうはなりません。Webエンジニアとして就職するための最低限の権利(ポテンシャル採用枠に滑り込める)を手に入れただけであって、まだまだ多く学ぶことは残されています。私の場合、転職後に何を学ばなくてはならないかが明確に分かったため、TechAcademy卒業時に教えてくれていればなと思いました。
例えば、RailsエンジニアといえどもVue.jsなどのフロント、AWSなどのインフラ、Circle CIなどのDevops系、RspecやメタプログラミングなどRubyやRailsのさらに深い部分などなどです。こういったことに関して、コースの中で特に言及されていなかったため、卒業後にWebエンジニアとして食っていけるようにする、その部分を支援するということが弱いと感じました。
働きながら受講したため時間の確保に苦労した
残業が40~60時間前後の場合、正月やGWを挟まずに2ヶ月コースで最終課題まで行くのはかなり難しいです。コースの期間に関しては下記のような目安で良いと思います。これから受講する方へのアドバイスでも記述しますが、受講前にProgateでしっかり事前準備することでだいぶ難易度が下がります。
- 学生さんの場合:1ヶ月(長期休み中) or 2ヶ月(通常授業期間中)コース
- 残業がない社会人の場合:2~3ヶ月コース
- 残業が60時間を超える社会人の場合:3ヶ月コース
- 残業が80時間を超える社会人の場合:無理。スクールは諦め、マイペースで学習する。(Progate→Railsチュートリアルの流れ)
期間に関しては、3ヶ月を超える場合は高額過ぎるのでオススメしません。忙しい場合も事前準備をしっかりすれば3ヶ月程度で終わる内容です。一部チャットをのぞいていると4ヶ月、5ヶ月も継続しているらしき人がいましたが、事前準備を全くしてこなかったため課題についていけてなかったり、そもそもエンジニアとして向いていないことがやり取りから判断できたりで、金をドブに捨てている印象があったので真似をしないようにしましょう。
エンジニア経験者の場合、正直それほど質問することがない
初心者のうちは聞きまくった方が圧倒的に学習効率がよく、また解決できずに挫折することがなくなるため、メンター制度やSlackでいつでも質問できる制度は良いと思います。しかし、エンジニア経験者の場合、分からなければ自分で調べることもでき、いちいちSlackで聞くのが面倒です。そのようなレベルにある人については、かなり難易度が高まりますが、Progate後、そのままRailsチュートリアルに進み、その後オリジナルサービスを開発したり、よりレベルの高いスクールへ参加するという流れも選択肢として良いです。ただし、Railsチュートリアルは前提としている知識が多かったり、テスト駆動開発を取り入れているなど、難易度が比較的高めです。Railsチュートリアルを一度やってみて手に負えないレベルだと判断した場合に、TechAcademyを受講するのも悪くありません。
ポテパンキャンプと比較し、Railsエンジニアとして転職すること、にフォーカスしていない
これはここ数年乱立しているプログラミングスクールの多くに言えることですが*1、受講生が最終的にRailsエンジニアとして活躍していくことにピンを止めていません。Railsを学び、最終課題でオリジナルサービスを開発し、それを成果物として転職活動を行えることは、私が受講した当時には良いキャリアチェンジの手法でした。しかし、私の経験からも、これだけだと実際の開発現場では足手まとい程度の技術力しか手に入らず、最低限ポテンシャルがあると示せる状態にしかなりません。実際に転職後、働きながら大量の不足知識をキャッチアップすることとなり、講座内容と実際の現場にかなり乖離があります。
2018年10月現在では、本気で未経験からRailsエンジニアを目指す場合、ポテパンキャンプが最有力候補です。その理由は後述しますが、TechAcademyを受講するに適していることは下記の条件を満たす方です。
- 働きながらRailsを身に付けたい場合
ポテパンの場合、難易度が高く学ぶ量が多いため、他言語でのエンジニア経験者でなければ働きながらの修了は相当厳しいです。
- ガチでRailsエンジニアを目指す前に、まずWeb開発に自分が向いているかを試したい場合
ポテパンの場合、ゴールがRailsエンジニアとして就職となるため、目的がそうでない場合は過剰な内容です。
これから受講する人へのアドバイス
事前準備が大切です
TechAcademyの Webアプリケーションコースで使う技術の入門レベルは、Progateで学べます。
最低でも、HTML/CSS、Rubyのコースをやってから、できればRails、Command Line、Gitのコースを繰り返し身につけてからTechAcademyに参加するのが良いです。全部やっても1~2ヶ月程度で終わる内容で、月額1000円ぐらいなので2000円程度で学べます。
プログラミングの経験が浅い場合はTechAcademyはオススメ
Progateを繰り返し行うと、プログラミングの感覚が何となく掴めてきます。その後、TechAcademyでRails開発を学び、Web系の企業にエンジニアとして転職する流れは悪くないです。TechAcademyを受講するメリットはもう一度まとめると下記のようです。
- 基礎から段階を経て学ぶことができる、またSlackでの質問し放題やメンター制度により、挫折しにくく学習ペースを保てる
- Railsアプリを複数個開発する経験が得られ、Railsに慣れ、一定水準以上の技術力を身に付けることができる
- オリジナルサービスを作ることで、転職活動において成果物をアピールすることができる
特に未経験者で転職したい場合、企業側がその人の技術力やポテンシャルを判断する指標がないため、成果物をアピールすることで適性がある、Web技術をキャッチアップする素養があると判断され、ポテンシャル採用の対象と認識されます。私の転職活動においても、技術力が高くない設計屋としての前職からRailsエンジニアとしてポテンシャル採用されたのは、TechAcademyのコースを修了し成果物を完成させたことが大きな成功要因の一つです。
とりあえずどんな内容か知りたいという方は無料体験ができます。
Railsを学ぶ時にプログラミング未経験者がしてはいけないこと
Railsを学び始める時に時間とお金を無駄にするのは下記をすることです。私がRailsを初めて学んだ時にこの罠に引っかかり、多くのロスをしました。これからRailsを学び始める方はご注意ください。
まず、RailsはサーバーサイドのWebフレームワークであり、周辺技術のHTMLやCSS、Ruby、Gitなどに関しては最低限習得済みであることを前提に教材やコースが作られています。そのため、HTMLが全く分からない、Rubyって何?という状態だと、Railsが分からないというだけでなく、その前提知識も分からないとなり、分からないことだらけで100%挫折します。掛け算を学ぼうとしているのに足し算が良く分かっていない、経済学を学ぼうとしているのに高校数学が良く分かっていないのと同じで、無謀です。必ずProgateでHTML/CSS、Ruby、Git、できればRailsのコースをしっかり学んでから、スクールに入りましょう。
次に、Railsを学ぶ手段としてRailsチュートリアルがありますが、こちらは公式にも書かれているように別言語でのエンジニア経験者がメイン対象であり、初学者だと環境構築やGitなどのRailsとはあまり関係のない部分で長時間つまったりして完走率は著しく低いです。最初の方に熟練になろうというコラムがあるのですが、熟練になる前にだいたい挫折します。また、オリジナルサービスの開発がコース上にないため、転職活動時に成果物をアピールできません。Railsチュートリアルを独学で完了後、さらにオリジナルサービスも一人で開発できる初学者はほぼゼロでしょう。
Progateで基礎を習得後にRailsチュートリアルを行う場合、公式の動画や講座などのサポートが最近出始めましたがオススメしません。無料で公開されているものに対してあまりに高額であり、正直コスパが悪過ぎます。個人的には、無料公開のものに対して有料で補足するとか謎過ぎるだろ...という感覚があります。有料のサポートが出始めたという事実が完走率が低いということを証明しています。
そのため、Progate→TechAcademy→独学でRailsチュートリアル、の流れの方がお金を出すなら断然オススメ。TechAcademyを完了すればRailsチュートリアルも一人でできるようになります。もしくは、後述するポテパンキャンプに入るのが良いです。なるべくお金を掛けたくないという方はProgate後に一度お試しでRailsチュートリアルをやってみることをオススメします。難しければProgateで再度復習し、TechAcademyかポテパンで学ぶことでレベルアップを図り、独学で完走できそうであれば完走後に、自分なりにアプリを作成して転職活動に望めば良いでしょう。
ただし、長期間独学となるため、モチベーションや学習ペースの維持が難しいこと、コードレビューやアドバイスをもらう機会が皆無であり技術力向上が著しく非効率であること、転職関連の情報を集められないため就職に不利、またできたとしてもブラック企業に捕まる可能性が高いなど、デメリットが大き過ぎるのでオススメしません。企業側の視点に立っても、未経験で独学で学んでましたという志願者よりも、すでに卒業生が活躍している信頼あるスクールや転職エージェントでRailsを習得しましたという志願者の方が魅力的に映るのは言うまでもありません。
最後に、Railsを入門書籍で学習することは一番最悪の手段ですので、絶対に止めましょう。特に発売から半年以上すぎた書籍はゴミです。Web界隈の技術はすぐに移り変わり、更新がされない情報はすぐに陳腐化します。具体的には、環境構築で手順通りに行ってもエラーを吐き出して前に進まないなどの問題が頻発します。スクールやRailsチュートリアルの教材は日次や週次単位で更新されますが、書籍に関してはほぼ更新されません。別途HPの方で、補足や更新情報として上げている書籍もありますが、どこが誤った情報か分かりにくく、情報の更新も中途半端に終わることが多いです。また、書籍の場合、身近に知り合いののエンジニアがいない場合、質問する相手もいないので解決手段がなく、学習効率が著しく悪いです。
Railsエンジニアになりたいならばポテパンキャンプという選択肢もある
今年の8月末に News Pick で取り上げられ話題になりました。Railsを学び、かつWebエンジニアとして就職したいならば、最近話題のポテパンも良い選択肢の一つです。
お仕事決まれば全額キャッシュバック!転職特化型Ruby実践研修【ポテパンキャンプ】
こちらはProgateで基礎を習得した初学者を、Railsエンジニアに育て上げ、企業に紹介するためのスクール兼就職エージェントです。まず、Railsチュートリアルを1ヶ月で完了するようにサポートしてくれ、その後3ヶ月間Rubyの実践研修となり、合格すると企業へ紹介してもらえます。
ポテパンの良い点は、受講料が10万円と他のスクールよりも圧倒的に安いだけでなく、研修を突破し企業に就職できた場合その10万円がキャッシュバックされるため、実質的な受講料が0円であることです。また、研修内容もRailsエンジニアとして1年間実務経験を積むのと同等の課題となるため、就職率が格段に上がるだけでなく、配属後に技術力不足で切られる可能性が下がります。
ProgateでのHTMLやCSS、JavaScript、Ruby、Railsをマスターしていることが受講の最低条件ですが、本気でRailsエンジニアになりたいと考えている場合はTechAcademyよりも、まずポテパンの受講面談を受けることをオススメします。ポテパンの方が課題レベルが実践に近く、かつ現役エンジニアのレビューを受けられるため断然オススメ。その代わり難易度が飛躍的に上がるため、注意が必要です。なお、Twitterを漁ると出てきますが、Progateも終わっていない状態で面談に行くと不合格となり、研修を受けることができず門前払いとなるので注意しましょう。
RailsにRSpecを導入する手順
everyday Rails の第2章より必要な要素だけ抽出
目次
- RSpecの導入
- 出力フォーマットを読みやすくする
- binstubを使い、起動時間を短くする
- テスト用のファイルを自動生成する設定
RSpecの導入
Gemfile
group :development, :test do # ... gem 'rspec-rails', '~> 3.6.0' end
書き換えたら bundle install
binstubを使い、起動時間を短くする
Gemfile
group :development do # ... gem 'spring-commands-rspec' end
binstubの設定ファイルを作成
bundle install bundle exec spring binstub rspec
起動確認
bin/rspec
テスト用のファイルを自動生成する設定
下記の設定だとモデルとコントローラのスペックが自動で生成される。
config/application.rb
module Projects class Application < Rails::Application config.load_defaults 5.1 config.generators do |g| g.test_framework :rspec, fixtures: false, view_specs: false, # フィーチャースペックやシステムテストがあるため不要 helper_specs: false, routing_specs: false # routingが複雑になってきたらちゃんとテストしよう end end end
オススメの追加設定
下記記事の設定を追加すると、FactoryBot.create(:user)をcreate(:user)と書くことができるので楽
forest-valley17.hatenablog.com
Git - ブランチとマージ関連のコマンド一覧
ブランチを新規追加する
# ブランチは切り替わらないので注意
git branch <ブランチ名>
ブランチを切り替える
git checkout <既存ブランチ名>
# ブランチを新規作成して切り替える
git checkout -b <新ブランチ名>
ブランチの一覧表示
git branch
# リモート含めて、全てのブランチを表示
git branch -a
ブランチ名を変更する
自分が作業しているブランチ名を変更する。mはmoveの略。
git branch -m <ブランチ名>
ブランチを削除する
# masterにマージされていない場合は削除しない git branch -d <ブランチ名> # 強制削除する git branch -D <ブランチ名>
変更履歴をマージする
# ローカルリポジトリから作業中のブランチにマージ git merge <ブランチ名> # リモートリポジトリから作業中のブランチにマージ git merge <リモート名/ブランチ名> # 具体例1 - 自分がmasterブランチにいて、hotfixブランチの変更履歴をマージしたい git merge hotfix # 具体例2 - 自分がfeatureブランチにいて、masterブランチの変更履歴をマージしたい git merge master git merge origin/master # こちらはリモートリポジトリから
Tips
Gitを丁寧に学ぶ方法
リンク先の記事にまとめています。
ゼロから学ぶGitの勉強方法 - fv17の日記 - Coding Every Day
そもそもブランチとは?
- 分岐することで複数の機能を同時並行で開発するための仕組み
- ブランチとはコミットを指すポインタ(に過ぎない)
- 他の人の開発の影響を受けずに自分の開発が行える