Rubyのテストフレームワークのひとつであるrspecは、今日デファクトスタンダードといっても良い地位を占めています。実際、私が本業で関わっているシステムでも、rspecを用いてプロダクトの品質担保が図られています。
では、実際にビジネスの現場で稼働するようなシステム、言い換えれば複数のメンバーが同じタイミングで開発を進めていくようなシステムにおけるrspecのテストで、気にしておくべきこととは何でしょうか？ここではそんな観点で私の持論をまとめてみたいと思います。
今回は、
- 個人開発には習熟してきたが、現場でどのようなテストの書き方をしているのだろう
- 現場に初めてアサインされるにあたって、開発効率も考慮したテストを書いていきたい
というあなたに向けた、現場レベルで役に立つ実践的な記事となっています。
また、
- rspecの導入の仕方
- 基本の書き方の解説
はこの記事には含まれないのでご容赦ください。
Contents
describe / context / it の書き方に着目
複数人で開発を進めるにあたって、私が最も重視しているのは「他のメンバー、あるいは将来の自分が見ても読みやすいテストコードになっているか？」という観点です。要するに、テストコードを書く際には「将来にわたって読みやすいテストをいかに書くか」という視点を持っています。
読みやすいテストを書くために、ここではdescribe, context, itの書き方に着目します。
結論を言うと、私はこちらの記事も参考に、
- describe → テストするメソッドを記述
- context → ブロック内でどういったケースをテストするか記述
- it → 期待する結果を記述
というような書き方をするよう心がけています。このように書くメリットとして、先述したように他の人がみたり、自分で後から見返したりする時にテスト概要が把握しやすいという点があります。
以下はその書き方のサンプルです。業務内でのコードをむりくり公開できるように書き換えたので、動作は保証できない点ご了承を。
require "rails_helper"RSpec.describe SampleService, type: :service do before(:each) do @user = FactoryBot.create :user @text_template = FactoryBot.create :text_template end describe "#create_by_template" do context "引数にいずれも望ましい値が渡される場合" dosubject { SampleService.create_by_template(template_params, @user) }let(:template_params) do { name: "text_name_1", text_type: :comment, }endit "正常にTextが作成される" do expect(subject.name).to eq(template_params[:name])end end context "第２引数userがnilの場合" do...この書き方をした場合、テスト失敗した際に非常に分かりやすいログが出てくれるのも魅力的です。
$ bundle exec rspec...Failed examples:rspec ./spec/service/sample_service_spec.rb:xxx # SampleService#create_by_template 引数にいずれも望ましい値が渡される場合 正常にTextが作成されるご覧の通り、describe / context / it における記載内容が一文として表示され、どこの何で失敗したかが一目でわかります。
例えばこのような書き方をテストではするようにコーディングルールとしてチームで定めておけば、運用保守においても読みやすいテストをチームとして生み出すことが可能になるでしょう。また、rspecに不慣れなメンバーがジョインした際も、一種の「書き方の規範」として案内しやすくなります。
