はてなブックマーク

こんにちは、endo と kawabata です。 今回はプロダクトチーム内の自動テスト改善チームでコツコツカバレッジを上げた取り組みと振り返りのお話をしたいと思います。 ここでテストのカバレッジを上げているのは、RSpec でのお話になります。 テストのカバレッジを上げていこうというお話は、こちらの食べチョクの自動テスト改善活動 〜これまでとこれから〜のお話からきています。 ゴールを設定せずに活動するのは良くないので、10 月末までにカバレッジを 80%まで上げるということを目標に設定しました。 80%まで上がれば広範囲をカバーできているだろうというざっくりとした見立てです。 今回の取り組みでは、大きく分けて以下の 3 点を実施しました。 どのテストを追加するか決める コツコツテストを追加する 不要なコードを削除する どのテストを追加するか決める テストのカバレッジを上げていこう！という

こんにちは。プロダクト開発チームの Engineering Manager 兼 人事の @hirashun です。 利用率No.1の産直通販サイト「食べチョク」を開発/運用するビビッドガーデンではリリース当初からバックエンドをすべてRubyで開発しており、ユーザーに迅速なサービス提供ができる恩恵を最大限にあずかっております。 この度RubyKaigiが3年ぶりのオフライン開催@三重県ということで、Rubyコミュニティーに何か恩返しは出来ないことか・・・と考えた結果、 ビビッドガーデンは"Mie Food Sponsor"として三重のこだわり食材を携えて協賛することにしました！ こだわりをもってRubyで開発を続けるみなさんに、三重の生産者の方々のこだわりをたっぷりお届けします！是非RubyKaigiで三重の魅力もお楽しみください。 三重のこだわりお届けします オフライン参加の方だけでなく、

皆さんこんにちは、エンジニアの久保と金田一です。 今回は、食べチョクの自動テスト改善チームが取り組んでいるテスト実行速度の改善についてお話しいたします。 自動テスト改善チームとは何か？について知りたい方は、以下のエントリーをご覧ください。 食べチョクの自動テスト改善活動 〜これまでとこれから〜 食べチョクにおける自動テストの現状 食べチョクでは、GitHub Actions のワークフローを使って、push をトリガーに自動テストを実行しています。食べチョクのリポジトリには System Spec までを含んでいて、E2E は別リポジトリとなっています。 メンバーが増えて体制が整ってきたこともあり、この 1 年くらいに実装した機能についてはテストがしっかり書かれていることが多いです。一方で、それ以上前に作られた機能については、まだまだカバレッジが低い箇所もあり、みんなで手分けして少しずつテ

みなさん初めまして。 QAエンジニアのujeです。 食べチョクでは、2022年4月から正式に自動テスト改善チームが発足いたしました。 チームメンバーは機能開発との掛け持ちにはなりますが、Webエンジニア5名・QA1名で取り組んでいます。 自動テスト改善チームの発足に伴い、食べチョクのテストにまつわる振り返りと、改善チームが取り組んでいることをお話しいたします。 これまで 食べチョクはサービスリリースから5年がたつプロダクトです。 特にここ1年半は食べチョクに参加してくれる仲間が増えており、サービス開発のスピードも上がっています。 食べチョクは2020年まで、テストカバレッジが低く、またなかなか向上しない状態でした。 システム全体に影響がある改修をする際は、毎回全画面を一通り手作業で触りテストするなど労力のかかる状態でした。 この状態を脱するため、2020年末から少しずつ自動テスト改善の動き

こんにちは。 食べチョクの開発を副業でお手伝いしているプログラマーの花村です。 監査ログをJSONL（JSON Lines）のファイルに記録するためのGemのAuditLoggableを作成してrubygems.orgで公開しました。 ソースコードもGitHubで公開しています。 ​ rubygems.org github.com なぜ開発したのか 食べチョクでは監査ログを記録するためにAuditedを利用していました。 AuditedはActiveRecordのコールバックを利用してモデルの変更を手軽にRDBに記録してくれる大変便利なGemです。 しかしRDBに記録するためテーブルサイズが肥大化しパフォーマンスに影響を与える場合があるというデメリットもあります。 食べチョクでは注文数の増加に伴ってこの問題に直面しました。 これを解決するにあたり以下のようなアプローチが思いつきます。 監査

皆さんこんにちは、エンジニアの西尾です。 あなたは今、コードレビューをしています。 以下コードに直面したとき、何を指摘しますか。 修正してほしい点を、どのようにレビュイーに伝えますか。 // これはJavaScriptのコードです。 // 商品の在庫を1つ減らし、売り切れになったものを抽出したい、と思っています。 const soldOutProducts = products.filter(product => { product.quantity -= 1; return product.quantity <= 0; }); よくないコードレビューの例 問題は表題の通り、filterの中で状態を書き換えているのが、よくありません。 関数型言語を学んだことがある方なら、このコードの違和感に気がつきます。 filterは純粋関数であるべきだ、副作用を起こしてはいけない。そう認識しているから

こんにちは。 今年の年始からジョインした遠藤です。 さて、入社したところ会社支給のMacBook ProがM1チップのものでした。 はい、現状は開発環境で苦労するとか色々噂を聞くやつです。 実際に試したのですが、 現状の開発環境構築スクリプト、手順書が一切使えない VitualBox, Vagrantは利用不可 Dockerは利用可能ではあるが、一部イメージが対応されてない 古いパッケージは動かす手段がない などなど、通常ではぶつからない問題にぶつかります。 食べチョクでは、 Ruby Node.js MySQL Redis ElasticSearch Kibana を利用しています。 この辺りをメインに話つつ、Intel版とこんな風に違うのかっていう辺りの雰囲気を感じ取っていただければと思います。 どこに開発環境を構築するか まず、どこで開発環境を構築するかを考えてみたいと思います。 ロ

こんにちは。食べチョクの開発をお手伝いしているフリーランスエンジニアのもぎゃ です。 ぼくも記事書いていいそうなので、最近食べチョクの開発をやっている時に発見したRailsテクニックの話を書きます。 バリデーションメッセージのつらみ Railsでバリデーションをつかって入力をチェックしている場合、@model.errors.full_message をエラーメッセージとして出すことができます。 Active Record バリデーション - Railsガイド ただ、ぼくらが作ったモデルの日本語名までRailsが知っていてくれるわけではないので、"User Messageを入力してください"みたいな分かりづらい文字列になってしまうことがあって、この場合i18nのリソースを適切に書いてあげることでエラーメッセージを改善することが出来ます。 Rails 国際化 (i18n) API - Rail

皆さんこんにちは、エンジニアの西尾です。 2019年9月24日(火)、フジテレビ系列のテレビ番組 「セブンルール」 にて弊社代表およびサービスを取り上げていただきました。 テレビ放送開始直後、サイトにはいままでにないアクセスが押し寄せましたが、 システムを落とすことなく、かつパフォーマンスも落とすことなく無事に稼働させることができました。 今回はテレビ放送前に、食べチョク開発チームが行ったパフォーマンス対策を紹介いたします。 開発チームのミッション 放送日が決まった時、代表が一言、Slackにつぶやきました。 サーバーを落とさない 放送中にサーバーは絶対落とさない。 この日から少しずつパフォーマンス対策を始めることにしました。 食べチョクのシステム構成 食べチョクはAWS上で運用しており、構成はとてもオーソドックスなものとなっています。 EC2,ELB,RDS,ElasticCache(R

皆さんこんにちは。エンジニアの西尾です。 今日は仕事を任せられるようなエンジニアになるために意識してほしいことをまとめましたので、ここに公開いたします。 もともとは社内向けに公開したものです。 この文章は私がビビッドガーデンに入社する前の、前職での経験を踏まえて書いています。 今の食べチョクエンジニアが意識できていない、という話ではありませんのでご注意ください。 意識面 作業の見積もりができる 技術力が低い（コーディングができないなど）よりも敬遠されるエンジニアは、作業の見積もりができない方です。 第一線で活躍している方は、作業見積もりが他の方に比べて正確です。 見積もりをするためには、どういう設計をして、どういう機能を作り、どういう影響範囲があるのかを正しく理解する必要があります。 見積もりができないということは、作業内容を正しく理解できていない、技術的な困難性を理解していない、不確定要

こんにちは。エンジニアの西尾です。 食べチョクのステージング環境では、本番環境のデータを日次で同期して利用しています。 今回はステージング環境の役割と、どのようにデータ同期をしているのかについてご紹介いたします。 ステージング環境 食べチョクでは、手元のマシンでプログラムを修正しコードレビューを実施後、改修内容をステージング環境にデプロイしています。 ステージングは、本番へのリリース前に修正箇所の動作確認・検証する環境です。この環境で動作や性能に問題がないかを確認後、本番環境へのデプロイを実施しています。 ステージング環境には、本番と同等のデータが入っています。 リリース当初は、ステージング環境と本番環境のデータは同期しておらず、テスト用のダミーデータで動作確認を行っていました。 しかしダミーデータでの確認だと、 ダミーばかりが並んだサイトと本番環境では見た目や印象が違っていて、UIが最適