はじめに
実務未経験の自分がエンジニアスクールでレビューを頂いた時に、
おそらく現場でも指摘されるであろう項目をまとめていきます。
前回は、コード・文法編をまとめました。
【初心者向け】独学では気づきにくい！実務未経験がプルリクエスト時レビュアーに指摘されたこと-コードお作法編-
まとめきれていない部分もありますので、随時追記していきます。
特に、独学でRails等を学んでいる方の参考になれば幸いです。
1. コミットでの注意
わかりやすく、綺麗なコードを書くことは心がけているに、雑なコミットで残してませんか？
私が独学で勉強していた頃は、正直疎かにしてました。
しかし、プルリクエストでレビューしてもらう際やチーム開発では、理解しやすいコミットを残す必要があります。
特にコレが正解！というのはありませんが、指摘されたことを踏まえてまとめていきます。
1-1. １つのコミットで複数の機能を追加するのは避けよう。（意図を理解しづらくなる）
一気に複数の機能を実装して、1つのコミットにまとめると見る側が意図を理解しづらくなります。
$ git commit -m "ログイン機能、ユーザー編集機慧能、画像投稿機能およびRspecテストを追加"
のようにしてしまうと、
メッセージ的にもコードを確認するにしても分かりづらい状況になります。
コミットをどのように分けるかは、常に意識する必要があります。
1-2. 理解しやすいコミットメッセージ
コミットメッセージには、端的に理解しやすいメッセージで残す必要があります。
- どういう目的で
- 何を
- どうしたのか（追加・修正・更新・削除など）
をコミットメッセージに残せると見る側も意図を理解しやすそうです。
とはいえ、チーム・プロジェクトによりルールがあると思われますので注意が必要。
個人的には以下のURLで紹介されていた書き方が分かりやすいかなと感じました。
参考URL: 誰にとってもわかりやすいGitのコミットメッセージを考える
1-3. 不要なファイルは除外or削除しよう
自動生成されるけど不要なファイルは事前に必要かどうかを考えましょう。
そして、本番環境で不要な.env（環境変数）などのファイルは、事前に.gitignoreに記述して除外しておきましょう。
不要なファイルがコミットされれば、自分・レビュアー共に見づらいプルリクエストになってしまう。
2. RSpecの準備編＜導入後＞
group :development, :test do
gem 'rspec-rails'
gem 'factory_bot_rails'
end
で、bundle install後に準備すると良いものをまとめます。
基本設定などは、[Qiita] Ruby on Rails のテストフレームワーク RSpec 事始めなどがオススメです。
2-1. 結果を見やすくする
通常何も設定せずにRSpecテストをすると
...
Finished in xx seconds
3 examples, 0 failures
テストに失敗していないことは分かりますが、詳細が分かりにくい状態に。
そんな時は、
.rspec に format documentationを入れて結果を見やすくすると良い。
※個人的にもレビューをして頂いている方にも見やすいテスト結果になります。
--require spec_helper
--format documentation
例えば、このように出力されます。
Sample::HomeController
Home Controller indexの機能テスト
sample/に正常にアクセスできる
Sample::ProductsController
Prodcut Controller showの機能テスト
products/showに正常にアクセスできる
@productが取得できている
Finished in xx seconds
3 examples, 0 failures
2-2. FactoryBotを設定しておく
RSpecでFactoryBotを使う場面があると思います。
何も設定をしない状態では、
let!(:product) { FactoryBot.create(:product) }
FactoryBotを毎回書く必要があります。
これでは、作業効率的にあまり良くないので、rails_helper.rb定義しておくと良いです。
RSpec.configure do |config|
config.include FactoryBot::Syntax::Methods
end
見た目もすっきりして、呼び出せるようになりました。
let!(:product) { create(:product) }
詳しい設定方法などは、こちらの記事がオススメです。
参考URL： RailsアプリへのRspecとFactory_botの導入手順
3. RSpecのお作法編
RSpecを書いていく上で指摘されたお作法についてまとめています。
3-1. テストの文言を考える
機能単体テスト(feature test)で考えれば、
- featureは「どのような機能」
- scenarioは「ユーザーから見たサービスの挙動」
ということを踏まえて文言を考える。
例)
feature '商品の詳細ページを見ることが出来る' do
scenario '詳細ページにアクセス時、商品名や価格などの情報が表示される' do
end
scenario "関連商品をクリック時、商品詳細ページへ移動する" do
end
end
適当な文言設定をすると分かりにくいテストになり、確認する側も意図を理解するのに時間がかかります。
参考URL：
使えるRSpec入門・その4「どんなブラウザ操作も自由自在！逆引きCapybara大辞典」
使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」
3-2. 検査するDOM(HTML)の範囲を絞る
withinを使うことで、対象範囲を指定することができます。
これにより正確に意図したテストを実行することができます。
例は以下になります。
# id="add_to_cart"で探せるようにする
<div id="add_to_cart" class="btn-area">
<%= link_to cart_page_path do %>
<div class="btn btn-primary btn-block">
カートへ入れる
<i class="fa fa-angle-right" aria-hidden="true"></i>
</div>
<% end %>
</div>
scenario "カートを入れるをクリック時、買い物カゴページへ移動する" do
# id="add_to_cart"の範囲を指定したテストをする
within "#add_to_cart" do
click_on "カートへ入れる"
end
#現在のページがカートページであることを確認
expect(page).to have_current_path cart_page_path
end
参考URL：
Capybaraチートシート#スコープを切る
3-3. RSpecを設置するディレクトリを考える
分かりやすいディレクトリ構成にすると良いでしょう。
例えば、
app/controllers/products_controller.rbに対応するRSpecは、
rspec/requests/products/products_controller_spec.rb
が分かりやすい。
RSpecテストのファイルが多くなってくると、一目でファイルを探すのに苦労する場面も。
分かりやすいディレクトリ構成にすることで、ストレスを少しは軽減できると思います。
まとめ
今回は、コミット・RSpecで注意された点をまとめました。
まだ、細かい点などもありますので、まとめ次第追記いたします。
RSpecについては、独学で学習している頃は苦手意識があり敬遠していましたが、
指摘されることで少しずつ理解が深まってきた印象です。
現場等でエンジニアをやられている方で、本記事に間違い等ございましたら、
大変恐縮でありますがご指摘いただければと存じます。
よろしくお願いいたします。
RSpecの勉強に使用した著書：
「Everyday Rails - RSpecによるRailsテスト入門」