質とスピード(2022春版、質疑応答用資料付き)
(この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました) 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト(TDD)で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする&機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO(プロダクトオーナー)に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
おお、その話ですか、キュウリのサンドイッチの話でしたら拙者にお任せくだされ(早口)。 そもそもキュウリというのはインド周辺を原産とする植物でしてな、大航海時代に香料と一緒に西洋に広まりました。 日本にはシルクロードを通って陸路で伝わっておりましてな、途中に「胡」の国がかつてありまして、そのルートを通って入ってきたものには「胡」の漢字を充てるのです。 胡瓜(きゅうり)、胡椒(こしょう)、胡豆(そらまめ)、胡桃(くるみ)、胡麻(ごま)、などですな。 一方で、西洋には海路を通って伝わったわけです。 当時の西洋の貴族では自宅に植物園・菜園を所有しているのが当たり前でして、ま、ま、当初は観賞用植物として広まったようですが。 キュウリのサンドイッチはそのような菜園を所有している貴族の最大限のおもてなしだったのです。 当然、そのレシピとしては午後のティータイムに合わせたシンプルなものです。 キュウリはで
リーダブルなテストコードについて考えよう~VeriServe Test Automation Talk No.3~で発表した資料です。 【発表資料中のURL】 ※複数ページで出てくる場合は、初出のページ数に掲載 ◆P7 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 ◆P17 リーダブルテストコード / #vstat ◆P43 見てわかるテスト駆動開発 ◆P46 JaSSTレポート(過去のJaSSTの講演資料などが載っています) ◆P47 Agile Testing Condensed Japanese Edition ◆P48 A Practical Guide to Testing in DevOps Japanese Edition ◆P49 The BDD Books - Discovery (Japa
目次 目次 はじめに(本記事の見どころなど) テストについて話し合わなくてはならない テストの目的 「うまくいかないかもしれないものは何ですか?」 なぜテストをするのですか? この場合に限り…… テスト駆動開発 〜テストについて語る前に説明が必要です〜 テストについて話しましょう なぜすべてのテストを自動化しないの? テストカバレッジは有用な指標ですか? 「テストをシフトレフトする」とはどういう意味ですか? いつ、どこでテストすべきですか? 十分なテストとはどれくらいですか? おわりに はじめに(本記事の見どころなど) 今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」(原題は「We need to talk about testing」)を翻訳したので紹介します。 dannorth.net 本記事はDaniel Terhorst-North(Dan North
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの? ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ!」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
日本列島、暑くなって参りました。新型コロナウイルスの影響でステイホームされている方も多いかと思いますが、ここ数日の東京は半袖でも十分な陽気ですよね。そんなこれからのシーズンに大活躍するのが「そうめん」です。 我が家は少なくとも週2、多いときは週4くらいで そうめんのお世話になるんですが、みなさんのご家庭ではどんな感じでそうめんを食べていますか? 今回はその辺りにも触れつつ、私(P.K.サンジュン)の実家に伝わるそうめんの薬味『きゅうりのヤツ』の作り方をご紹介いたします。 ・我が家流「そうめんの食べ方」 そうめんの主役はもちろん「そうめん」ですよね。加えて挙げるなら「つゆ」でしょうか。ただし、我が家ではやや捉え方が違って、そうめんが主役であることは間違いないんですが「薬味」も同じくらい重要なポジションを占めています。 なんなら、我が家のそうめんは「そうめんを利用して薬味を食べる料理」と言って
When we introduced a default setup for system tests in Rails 5.1 back in 2016, I had high hopes. In theory, system tests, which drive a headless browser through your actual interface, offer greater confidence that the entire machine is working as it ought. And because it runs in a black-box fashion, it should be more resilient to implementation changes. But I'm sad to report that I have not found
RubyやRailsのアップグレードを主なマイルストーンとしつつ全体的に開発体験を良くしていくというタイプの仕事を請けることが多いのですが、仕事を依頼する側の視点に立ってみると「実際のところ業務に参加するとどういうことが行われるのか?」というのがやはり気になると思います。 実際、最近の打ち合わせでもその手の不安について相談されることがあったので、ここ1ヶ月でそれ系の仕事で出したPull Requestを元に、実際に何をやっていたかの例を挙げてみたいと思います。 開発環境構築手順や説明方法の改善 荒れたRuboCopの改善 .rubocop.ymlからTargetRailsVersionを取り除く DEPRECATION WARNING対応いろいろ 既存のメソッドと名前が被っているスコープを別名に変更 RSpecのpositional-argumentsを置換 activerecord-im
この記事は 食べログアドベントカレンダー2024 の12日目の記事です🎅🎄 目次 目次 はじめに 自動テスト作成の課題 テストケースを考えることの難しさ テストコードに落とし込む作業の負担 テスト対象のコード例 RSpecでのテストコード例 自動テスト作成の課題がもたらす影響 生成AIと自動テスト 自動テスト作成の効率化を目指して 導入の条件 Difyを活用したチャットボット チャットボットの利用方法 テスト生成の障害 実装コードをそのまま送った場合の問題点 良い自動テスト生成が可能なケース プロンプトの工夫 プロンプトや対話の工夫では解決できないこと 設計の重要性 まとめ ロジックを切り出した対象での有効性 自動テストと設計の相乗効果 最後に はじめに こんにちは。食べログ開発本部 ウェブ開発2部 第1プロダクトチームで主にバックエンド周りの開発を担当しています、エンジニアの高田です
ソーシャル経済メディアNewsPicksを開発・運営する株式会社ニューズピックスは2021年9月、これまでサーバサイドの主要な開発言語としてきたJavaに代えて、Kotlinをメインに採用する方針を明らかにしました。 ▶ NewsPicksのサーバーサイド言語をJavaからKotlinに切り替えるために - Uzabase Tech Androidアプリだけでなくサーバサイドも「Kotlinで開発できるようにする」というこの宣言の背景には、数年間にわたってマイクロサービスを中心にKotlinを採用してきた実績と知見の蓄積があるだけでなく、そういった現場からの挑戦をよしとするNewsPicksのエンジニア風土も大いに追い風となっています。 この挑戦をどのように進めようとしているのか? 開発者体験(DX)をどのように高めようとしているのか? NewsPicksのCTOを務める高山温さん(上写真
長年の運用で「Gemfileはこう運用すると上手くいった」という知見が蓄積されてきたので、ここに書き出してみておく。 Bundler/OrderedGemsを有効化する RuboCopの Bundler/OrderedGems Copを有効化する。 悪い例: gem 'puma' gem 'jbuilder' 良い例: gem 'jbuilder' gem 'puma' セクションを分けない 基本的に、独自の判断で空行を入れてセクションを分けたりしない。 ここで言うセクションとは「空行で区切られた1つのまとまり」のことである。Bundler/OrderedGems は、このまとまりの中で辞書順であることを要求する。 悪い例: gem 'aws-sdk-rails' gem 'aws-sdk-s3' gem 'graphql' gem 'graphql-batch' 良い例: gem 'aw
はじめに テストコード一般の考え方 壊れにくいテストを書く 実装した通りに動作することではなく、仕様通りに動作することをテストする テストコードはシンプルにわかりやすく書く 失敗の原因がわかりやすくなるように意識する RSpecの書き方 テストケース名をitの引数で明記する letよりもlet!を使う 通常の変数と同じ方針に基づいてlet!を利用する subjectを使わない 不要なcontextでのネストを避ける matcherを適切に使い分ける factoryのデフォルト値に依存しないテストを書く 参考にしたブログ記事等 付録:RuboCop設定 We are hiring! サムネイル画像 はじめに テストコードを書く習慣も、近年ではかなり一般的なものになってきました。 ドワンゴ教育事業のバックエンドチームでも自発的にテストコードを書く文化は根付いており、実際に計測はしていませんが、
さまざまなテストレベルとロールで活躍されている方々がテストコードをリーダブルにする方法について語り、それぞれの違いや共通点について議論する、「リーダブルなテストコードについて考えよう」。ここで株式会社ソニックガーデンの伊藤氏が登壇。リーダブルなテストコードとは何か、リーダブルなテストコードを書くための具体的な意識を紹介します。 伊藤氏の自己紹介 伊藤淳一氏:リーダブルコードという発表です。いきなり余談から入りますが、今日仕事をしていたらテストコードに助けられました。 仕様変更がいつ入ったのかを調べなきゃいけなくなってコミットを追いかけていったら、過去の僕がすごくわかりやすいテストコードを書いていて、仕様Aを仕様Bに変えることがdiffを見れば一目瞭然というようなものを作っていました。リーダブルなテストコードを書いてて良かったと思った日がこの勉強会の開催日で、ナイスタイミングだと思いました。
CTOの藤村です。つい最近まで STORES ブランドアプリ のチームでRailsを書いていました。 STORES ブランドアプリ のRailsリポジトリではdatabase_cleanerを(strategy = truncationで)使ってテスト中のデータベースをリセットしており、このことがテストコードの品質、速度などで重荷となっていました。 これを、テスト実行時にテストコード自体を書き換えて改善する仕組みを作り、先日無事Transactional Testへの移行が完了しました。ということで気分がとてもよいので、どうやったか共有させてください。 課題 STORES ブランドアプリのRailsのテストコードは速度に課題がありました。 テストデータを片付ける仕組みとして、 Railsエンジニアにはお馴染みのdatabase_cleanerというGemを使っていました。database_
Karateとは Karateは主にe2eテストを自動化するツール。cucumber的なfeatureファイルを書くとそれを実行できる。WebAPIのテストがその中心的ターゲット github.com graalvmのjsライブラリで実現しているっぽいので、featureファイルからJavaも呼べる。 個人的にBDDというのが結構いいと思っていて、ビジネスルールの仕様なんかをビジネスサイドと意識合わせする場合に使えると思っている。アンクルボブはFitnesseというツールを作っている。 FrontPage Fitnesseは名著『実践アジャイルテスト』でも紹介されていたもの 実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践) 作者:Janet Gregory,Lisa Crispin発売日: 2009/
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: History of RSpec – Steven R. Baker 原文公開日: 2021/05/09 著者: Steven R. Baker 日本語タイトルは内容に即したものにしました。 私がTDD(テスト駆動開発)をチームで教え始めたのは2001年のことでした。当時のTDDはまだかなり新しい概念でしたので、テストを自動化したチームもほとんどなく、XP(エクストリームプログラミング)やTDDについて聞いたことがある人も皆無でした。テストを最初に書くことで設計を進めるという概念は当時まったく知られていなかったので、TDDを理解するのに皆とても苦労していました(20年経った今でも、この事実が完全に変わったとは言えません)。 思い返せば、あの当時は厳しい状況でした。最善を尽くしてTDDの概念を説明し、どうにかしてチームの関心を惹こう
株式会社アンドパッドのアカウント基盤チームでテックリードをしているid:shiba_yu36です。 最近自分のサイドプロジェクトとして、生産性を向上するために、CI実行時間の短縮化を行っていました。その結果、とくに時間のかかっていたCircleCI上のRSpecによるテスト実行時間を、25min -> 12minに改善できました。そこで今回はどのような流れでCIの実行時間を改善していったかについて、具体的に書いてみたいと思います。実行時間改善の勘所について参考になれば幸いです。 改善の流れ: CircleCIでボトルネック調査し、大きいボトルネックを解消する 実行速度改善の前に: Flakyなテストを一斉に直す 速度改善1: bundle installのキャッシュがうまく効いていなかった問題を修正 -> 4minの短縮 速度改善2: developブランチ以外ではカバレッジを取らないよう
Ruby on Rails Advent Calendar 2021の枠が空いていたので、あとから登録しました はじめに 個人的なプロジェクトになりますが、僕が翻訳しているRSpecの入門書「Everyday Rails - RSpecによるRailsテスト入門」を2022年前半にRails 7.0バージョンにアップデートしようと考えています。 そこでこの本の中で使っているサンプルアプリケーションをRails 7.0でゼロから作り直してみました。フロントエンド周りを中心に結構考え方が変わっている部分があったので、「ここでハマった!」とか「こういうポイントを押さえておくといいかも」という点をあれこれ書いてみます。 なお、Rails 7.0版のサンプルアプリケーションはまだ公開できる状態ではないので、公開はもうしばらくお待ちください🙏 今回作成したサンプルアプリケーションはこちらで公開してい
はじめに テストダブル(Test Double)について、わかりやすく解説した技術記事はないかな〜と探していたところ、こちらのブログ記事を見つけました。 goyoki.hatenablog.com とても詳しく解説されていたので、まさに打ってつけだったのですが、ふだん僕はRubyを使っているのでサンプルコードをRubyにしてみたいな〜と思いました。 そこで今回のエントリでは、原著者の id:goyoki さんの許諾をいただいた上で、上記のブログ記事の説明文を維持したまま、サンプルコードだけをRubyに書き直してみました。(goyokiさん、どうもありがとうございます!) ただし、Ruby版のコードにあわせて説明文を改変した箇所もいくつかあります。 それでは以下がRuby版の「xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の
はじめに 僕は折に触れて「RSpecではなるべくsubjectを使わない方がいい」という発言をしています。 Qiitaとか見てるとRSpecのsubjectを愛用している人が多そうな印象なんだけど、僕はほとんど使っていません。「subjectは原則使わない。明らかにメリットがあるときにだけ例外的に使用する」が僕のポリシーです。ほら、RSpecの(元)メンテナさんもそう言ってるし。 https://t.co/Rp5EiIxCVb #Qiita pic.twitter.com/pMlN35ihEG— Junichi Ito (伊藤淳一) (@jnchito) 2019年5月28日 そもそもの話として、RSpecではsubjectは無理に使わない、というのが僕の持論です。なぜなら無理にを使うと、いびつなテストコードができやすいから。基本はsubjectなしで書く。明らかにsubjectが有効なと
はじめに 読みやすくメンテナンスしやすいRSpecを書けていますか? RSpecはというかRubyはというか柔軟なので色々な書き方ができてしまいます。 ある程度の規模のテストコードでは、油断するとどこで定義されている let なのかわからないものが登場したり、なぜか作られる(あるいは作られない)謎のレコードでテストが失敗したり、そういった辛い目にあったりするのではないでしょうか。 僕がRSpecを書くときに意識していることをまとめてみました。 これを実践するようになってつらい現象にあうことはずいぶんと減り、ずいぶんと読みやすくなったんじゃないかなと思っています。 ※効果には個人差があります。 Ruby on Railsを使ったアプリケーションのテスト向けですがRuby on Rails以外でも使えると思います。 主に以下の影響を強く受けています。 RSpecとセットで使われることが多いFa
こんにちは。Optimal Bizのサーバーサイドに関する開発を担当している伊藤です。 皆さんCIは何を利用していますでしょうか? Optimal BizではGitLab CI/CDを利用しています。 単体テスト・ビルド・デプロイ等CIの用途は多岐にわたりますが、実際にそれらを実行するPCを必要な数だけ常に起動しておくと無駄な料金がかかってしまいます。 そこで、今回はGoogle Cloud Platform(以降、GCP)のプリエンプティブル VM インスタンスをGoogle Kubernetes Engine(以降、GKE)でオートスケールさせることで、CIリソースを格安で確保する事例を紹介します。 利用例 Optimal Bizチームの場合は「RSpecをGitLab CI/CDを使って並列実行する」で紹介した大量の単体テストを約20台のノードで並列実行するために利用しています。 ざ
Rubyでテストがこれほど盛んな理由のひとつはRailsの存在にあると私は信じています。Railsフレームワークはテストをできる限り楽しく書けるようにしてくれます。ほとんどの場合、網羅的なRailsテスティングガイドを参照すれば事足ります(少なくとも最初のうちは)。しかし物事に例外はつきものです。私たちの場合「システムテスト」がそれでした。 テストをページのマークアップから切り離す方法については、「Railsシステムテスト」シリーズの次の記事『System of a test II: Robust Rails browser testing with SitePrism』をご覧ください。 Railsアプリケーションでシステムテストを書いたりメンテしたりするのは、正直「楽しい」からほど遠い作業です。この問題に対処するために用いた私のアプローチは、今を去ること2013年に初めてCucumber
STORES 予約 でwebアプリケーションエンジニアをやっております。ykpythemindです。 皆さん、Webアプリケーションのテストを書いていますか。 モック(mock)を使っていますか。 今回は自動テスト上で、偽物だけではなく(要所で)本物を使おうよという話を書きます。 想定読者としては主にRuby on Railsを開発しているバックエンドエンジニアを想定しています。 モックとは 今回のモックの定義は以下にしておきます。 *1 実際の外部サービスや内部サービスの代わりをする偽のサービスを作成することです。 ref: https://circleci.com/ja/blog/how-to-test-software-part-i-mocking-stubbing-and-contract-testing/ Rubyでは外部サービスとの接合部で、 RSpecの allow(xx).
はじめに こんにちは、WEARバックエンド部バックエンドブロックの塩足です。普段は弊社サービスであるWEARのバックエンド開発・保守を担当しています。 WEARのバックエンドでは、これまで自動テスト環境としてCircleCIを使用していましたが、運用保守の改善を目的にGitHub Actionsへ移行しました。 今回は、GitHub Actionsへ移行する際に取り組んだ以下の3点について紹介します。 効率的にテストを分割してテストを並列実行する方法 失敗したテストのみを再実行する仕組みの構築 GitHubのCheck annotationsを活用して、失敗したテスト情報を表示 また、最後に今回行ったテストカバレッジのレポーティングとGitHub Pagesでのホスティングの方法について紹介します。 目次 はじめに 目次 背景 なぜ自動テスト環境をCircleCIからGitHub Acti
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Running Rails System Tests with Playwright instead of Selenium | justin․searls․co 原文公開日: 2024/06/18 原著者: Justin Searls -- Test Doubleの共同創業者です 日本語タイトルは内容に即したものにしました。 先週、DHHが「システムテストの導入は失敗だった」と宣言したとき、私の最初の心の声は「まあそうだろうね」でした。UIテストはもろいうえに、テスト件数がある程度以上になると、アプリが動作しているという確信をもたらしてくれるUIテストのありがたみよりも、UIテストをメンテナンスするコストの方が上回ってしまう可能性があります。 しかし、私の次なる心の声は「考えてみれば、Turboに強く依存した複雑なUIに対して
Test which reminded me why I don't really like RSpec | Arkency Blog (日本語訳:Rails: RSpecが好きでないことを思い出したテスト(翻訳)|TechRacho by BPS株式会社) を見ての感想。 元のコードのイマイチなところは 4 つあって、 params を before で書き換えている *1 it "will succeed" の文言 it { is_expected.to be_success } と expect(result.success?).to eq(true) が混ざっている let が不思議な順序で連発されていて事前条件を読み解けない すべて、これによって何をテストしているのかが分かりづらくなっているという問題を引き起こす。 params を before で書き換えている let(:pa
こんにちは。サーバーサイドエンジニアの三村(@t_mimura)です。 主に保険薬局と患者さまを繋ぐ「かかりつけ薬局」化支援アプリ kakariのサーバーサイド開発(Ruby on Rails)を担当しています。 今回はRailsシステムのCI時間をコスト追加なしで半減した話をします。 目次 前提 対象プロジェクト CIの状況 改善結果 改善内容 前提知識: CIのキャッシュ機能 webpack buildのキャッシュを活用 RuboCopのキャッシュを活用 ESLintのキャッシュを活用 Jestのキャッシュを活用 RSpec Jobをテスト特性ごとに分割 CircleCIのリソースクラスと並列数の最適化 採用しなかった・見送った改善候補 HAML-Lint, Fasterer, Brakemanのキャッシュを活用 Stylelintのキャッシュを活用 bootsnapを活用 Jestの
こんにちは、 ydah です。最近はというと、料理への情熱が再燃してきました。一時期は作った料理を全て写真に残していたりとしていたのですが、いつの間にか記録を何も残さなくなっていました。何かしら記録を残すことで、前回よりも味も見た目も良くしようと思えるので、記録を残していくようにしたいと思います。やっていくぞ〜!! トマトとタコのパスタの近影 はじめに 5/11-13 に長野県松本市 まつもと市民芸術館 で開催された RubyKaigi 2023 の Lightning Talks で、 RuboCop RSpec チーム*1と RuboCop RSpec から、 RuboCop Capybara と RuboCop factory_bot を gem に切り出した話をしました。 rubykaigi.org 当日の発表スライドは以下です。 この記事では RuboCop RSpec を現在使
この記事は ANDPAD Advent Calendar 2022 の 7日目の記事です。 qiita.com こんにちは、ydahです。 先日のRubyWorld Conference 2022で燗酒の美味しさに感動していたのですが、ふと気がついたら島根の日本酒がたくさん我が家にいました。 気が付くと何故か我が家にいらっしゃった方々(不思議だ...) そして、また気がつくと枡や徳利、平盃も我が家にいらした(不思議ですね...)のでこれから寒くなるので、燗酒を飲んで温まっていこうと思います。 はじめに 本記事では私が所属しているANDPAD検査チームで取り組んだ以下のことについて紹介いたします。 Request specの改善についてやったこと チームとして改善タスクやリファクタリングを推進するための仕組み作り Request specの改善について 長年、様々な人によって書かれてきていた
はじめまして。サーバーサイドエンジニアの kinakobo です。 唐突ですが、自動テストの実行にはどんなCIツールを使用していますか? 色々と選択肢があると思いますが、自分は今までCircleCI、GitHub Actionsを使うことが多く、ANDPADに入社して初めてCodeBuildでテストを実行しました。 それまでCodeBuildを使ったのはDocker imageの構築くらいだったので、あまりテストの実行に向いている印象は持っていませんでした。 ですが調べてみると意外と機能が充実しており、中でもテストレポート機能は便利だと思ったので今回紹介したいと思います。 テストレポート機能とは AWS CodeBuild でのテストレポートの使用 - AWS CodeBuild テストレポート機能は、テストのレポートファイルをいい感じに整理して表示してくれる機能です。 CircleCIに
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く