DBモデリングとRSpecのワークショップを行いました

皆さんこんにちは！2021 年の新卒エンジニア研修ではフリーランスのRailsエンジニアであるigaigaさんをお招きし2つのワークショップを行いました。1つ目はデータベース（DB）のモデリングについて、2つ目はRailsのテストフレームワークであるRSpecについてです！この記事ではそれぞれのワークショップの様子や学んだことについて参加したメンバーがお伝えして行きたいと思います！

DBモデリングworkshop

実施日：2021/06/23 資料：https://github.com/pepabo/training/blob/master/workshop/db_modeling/db_modeling.md

ここからは研修に参加した新卒11期エンジニアのゆうくんとやんまーがお送りします。

研修内容

研修は4時間のうち前半に座学を受け、後半に学んだ内容を実践する形で進みました。

前半はデータベースモデリング (以下DBモデリング) の概要と、DBモデリングを例題に沿って実際に行いながらポイントを説明していただきました。講義でご指南いただいた内容のうちのいくつかを以下に記します。

• DBモデリングとは、現実世界をデータベースの世界で扱えるようにするための設計である。(本研修ではリレーショナル・データベースを扱う)
• テーブル設計の順序に困ったときは次の手順に従うとよい。「テーブル名を出す」→「各テーブルのカラムを決める」→「表現できていない情報が無いか確認する」→「テーブルの関連付けを行う」
• テーブル設計にてテーブル名を考えるときは「誰が・何が」「誰を・何を」を意識すると考えやすい。例えばレストランのメニューにおいて「誰が注文するのか」を考えると「顧客テーブル」が必要だとわかる
• テーブル設計ののち、ER図を書いてカラムごとの制約 (一意性制約, 外部キー制約など) を考える
• 最後にできあがった設計をもとにプログラムに落とし込む。(Rails のマイグレーションファイルなど)

以上のような点を学んだ後、後半ではDBモデリングを受講者自身が実践しました。最後に各自の設計を発表しあい、igaigaさんや他の参加者、社内のエンジニアに意見をいただいて、それぞれの設計の良かった点と改善できる点を振り返りました。

演習時間にゆうくんが作成した図書館システムのER図

感想

研修を通して、DBモデリングの大切さ、難しさ、面白さを感じました。単純に思える対象でも様々なことを考慮すると意外と複雑になります。研修の中でも、自分が実践したDB設計についてフィードバックをいただけたことをありがたく感じます。ER図をもとにigaigaさんや他の参加者からの意見を聞いて、自分が見落としていた点に気が付かされました 。

特に印象に残っているのが「頻繁に削除されるレコードは、論理削除を採用すると将来的に数億くらいのレコード数になりうるので管理が大変では？」という指摘です。現場の声を交えた自分にはない視点の意見で、運用時を見据えた設計の大切さを実感しました。また、同じ題材をモデリングしても出来上がったER図が参加者ごとに大きく異なっていた点を興味深く感じました。それぞれの設計に長所や短所があり、他の設計をみることで自分の設計をよりよくできるヒントにもなりました。出来上がったER図が大きく異なっていたのは、DB モデリングの難しさももちろんですが要件をどのように定義するかも含めての実践課題だったことも一因に思います。実際の業務においても環境に合わせた要件の定義、設計の選択をする必要があるように思い、DB モデリングの奥深さを感じました。

Webアプリケーション開発を行う上でリレーショナル・データベースは必ず関連するといってもいい技術分野でしょう。ここで学んだことを配属後に活かし、人類のアウトプットを増やせるようなおもしろいサービスを開発していきます！

RSpec workshop

日程：2021/06/30

資料：https://github.com/pepabo/training/blob/master/workshop/rspec/rspec.md

ここからは研修に参加した新卒エンジニアのわたさん、ほみるん、やぎじんの3人がお送りします。

igaigaさんにRubyのテストツールの1つであるRSpecの研修を行っていただきました。

igaigaさんとの資料の共有や当日のやり取りは社内Slackにigaigaさんをゲストで招待する形式で行ったのでスムーズに行きました。また、会話を後日見直せるようになっています。

RSpecを学ぶ理由

一般論としてテストを書くことは開発を効率化するために必須であり、またペパボでなぜテストを重視しているかはこちらの記事にもある通りです。ですがあらゆるテストツールの中でもなぜRSpecについて研修を行うのか、hsbtさんにその理由を教えていただきました。理由は大きく2つあります。

1つ目はペパボのサービス開発においてテストをRSpecで書くことが多いということです。新卒エンジニア研修では冒頭でRailsチュートリアルを行うのですが、ここでのテストはminitestというフレームワークで書いていました。配属前にRSpecに慣れておこうということですね。

2つ目はRSpecに触れることで、テストフレームワークの主要な流派の1つであるxSpec形式に入門しようということです。世の中の多くのテストフレームワークのほとんどはxUnit形式かxSpec形式のどちらかに該当します（※）。その中でもminitestはxUnit形式、RSpec はxSpec形式に該当します。ここまで私たちはminitestを通してxUnit形式のテストには少し慣れてきましたが、今回RSpecを学ぶことで、Ruby に限らず新しいテストフレームワークに取り組む際のハードルが下がることが期待できます。

（※）xUnitやxSpecという言葉についてはこちらの記事を参考にしました。

研修内容

igaiga さんがチュートリアルを用意されていて、受講者は各自テキストを進めていき、気になった点や疑問点を直接igaigaさんに質問するという形式で進みました。チュートリアルで扱っている内容は以下の通りです。

• minitestとRSpecの違い
• よく使われるテスト3種類を実際に書いてみよう
  • Model spec: モデルに対するテスト
  • System spec: ブラウザを使ったアプリ全範囲のテスト
  • Request spec: ブラウザを利用しないアプリ全範囲のテスト
• RSpecの基礎文法
  • describeやcontextを使ってテストを構造化する
  • subjectやletを使って変数を定義する
• その他、便利機能
  • FactoryBot
  • モック、スタブ

この中でも特に印象に残ったトピックとして、minitestとRSpecの違いについて紹介したいと思います。 ここで示す例ではRailsアプリでBookというモデルが定義されているとして、メソッドtitle_with_authorが期待する文字列を返すか確認しています。

# minitest
class BookTest < ActiveSupport::TestCase
   test "Book#title_with_author()でBook#titleが文字列のときtitleとauthorを結んだ文字列があること" do
     book = Book.new(title: "Book", author: "pepayama botarou")
     assert_equal "Book - pepayama botarou", book.title_with_author
   end
end

# RSpec
RSpec.describe Book, type: :model do
  describe "Book#title_with_author" do
    context "Book#titleが文字列のとき" do
      let(:book) { Book.new(title: "Book", author: "pepayama botarou") }
      it "titleとauthorを結んだ文字列があること" do
        expect(book.title_with_author).to eq("Book - pepayama botarou")
      end
    end
  end
end

このように、minitest はマッチャー 想定テスト結果, テスト対象という形式であるのに対して、RSpec はexpect(テスト対象).to マッチャー(想定テスト結果)という形になる点が異なります。これはxUnit形式のフレームワークとxSpec形式のフレームワークに言える一般的な相違点なんだそうです。

感想

minitest はこれまで使っていましたが、RSpec という違う流派のテストに初めて触れて非常に新鮮でした。というかそもそも、2 つの流派があるということを知らなかったので眼から鱗でした。

あくまで個人的な印象ですが、RSpec の文法にはリーダブルになるような工夫が詰め込まれているなと感じました。describeとcontextはテストを区切るという機能は同じですが、テストの作成者がそこに込める意味づけが異なっていて、書き手と読み手の意思疎通をしやすいような配慮を感じました。

これまでテストを書くということを避けてきたところもありましたが、今回の研修を通してテストを書くことに対しての心理的ハードルが下がったように思います。これをきっかけにこれからテスト駆動開発についても学んでいきたいと思います。貴重な研修をしていただいたigaigaさん、本当にありがとうございました。