System tests have failed
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
コードメトリクスを計測・可視化する - Pepabo Tech Portal
今回は、データ基盤チームで進めている生産性ダッシュボードプロジェクトのサブプロジェクトとして進めているコードメトリクスを計測・可視化のための基盤について紹介したいと思います。 生産性ダッシュボードプロジェクトやその中心となるメトリクスであるFour Keysについては以下のエントリーやANDPADさんのポッドキャストでも紹介されていますのでぜひご覧ください。 ペパボテックブログ - エンジニアの活動情報からFour Keysを集計、可視化した話 datatech-jp Casual Talks #1 - データ基盤でFour Keysを可視化した話 ANDPAD TECH TALK 第10回 - 開発チームの生産性向上に取り組むスペシャリスト対談！前編 開発チームの生産性の可視化に興味を持った理由 ANDPAD TECH TALK 第11回 - 開発チームの生産性向上に取り組むスペシャリス
octocovはコードカバレッジを確認するCLIツールとしても使える - Copy/Cut/Paste/Hatena
octocovは私が開発しているコードメトリクス計測のためのツールキットです。 主となる用途であるCI（GitHub Actions）に組み込む使い方は会社のテックブログで紹介させてもらいましたのでそちらをご覧ください。 tech.pepabo.com 私自身もドックフーディングをしていて、自分の主だったリポジトリはすでに octocov に移行済みです。 Fix handling for bind runner by k1LoW · Pull Request #47 · k1LoW/runn · GitHub 実は octocov にはもうひとつ便利な使い方があるので、そちらを紹介したいと思います。 コードカバレッジを確認する octocov は実は単体のCLIツールとしても使うことができます。.octocov.yml といった設定ファイルも一切必要ありません。ただ、インストールするだけ
フロントエンドのテストは皆のためのもの | POSTD
テストとは人によって反応が分かれるものの1つであり、大喜びする人もいれば、見ないようにして去ろうとする人もいます。あなたがどちらの側であるにせよ、ここではフロントエンドのテストは皆のためのものであるということを説明します。実際、テストには多くの種類があり、それがテストに対して初めに恐れや混乱を感じる一因なのかもしれません。 この記事では、特に有名で広く利用されている種類のテストを扱います。なかには目新しいものはないと感じる読者の方もいらっしゃるかもしれませんが、少なくとも復習にはなるでしょう。どちらにせよ、筆者の目標は、この記事を通じて世の中のさまざまな種類のテストについて理解を深めてもらうことです。ここではユニットテスト、統合テスト、アクセシビリティテスト、ビジュアルリグレッションテストなどを一緒に見ていきます。 さらに、Mocha、Jest、Puppeteer、Cypressなど、各種
なんだかんだで1年半くらいRuby向けにブラウザの自動操作ライブラリを作っている - YusukeIwakiのブログ
かれこれ１年半くらい、Ruby向けのブラウザオートメーションツールをいろいろ趣味で開発している。 特に中身はないが、これまでやってきたことを少しサマリ。 はじまりはRubykaigi2020 思えば、開発を始めた動機は非常に不純で、「Rubykaigi 2020になんでもいいから出てみよう」だった。悪く言えば、ただ目立ちたいだけ。Puppeteerはなんとなく好きで触ってたので、「Rubyに移植したらなんかすごいんじゃね？」くらいの気持ちで実装を初めて、手応えがあればRubykaigi2020のCFPを出そうとしていた。 ところが、そうは簡単にいかなくて、WebSocketとasync/awaitで完全に手詰まりとなる。 yusukeiwaki.hatenablog.com それでもconcurrent-rubyとお友達になり歩み直して、最初のリリースは2020/04/05だった。全然CF
Railsでブラウザテストを「正しく」行う方法（翻訳）｜TechRacho by BPS株式会社
Rubyでテストがこれほど盛んな理由のひとつはRailsの存在にあると私は信じています。Railsフレームワークはテストをできる限り楽しく書けるようにしてくれます。ほとんどの場合、網羅的なRailsテスティングガイドを参照すれば事足ります（少なくとも最初のうちは）。しかし物事に例外はつきものです。私たちの場合「システムテスト」がそれでした。 テストをページのマークアップから切り離す方法については、「Railsシステムテスト」シリーズの次の記事『System of a test II: Robust Rails browser testing with SitePrism』をご覧ください。 Railsアプリケーションでシステムテストを書いたりメンテしたりするのは、正直「楽しい」からほど遠い作業です。この問題に対処するために用いた私のアプローチは、今を去ること2013年に初めてCucumber
reg-suit によるビジュアルリグレッションテストで Rails アプリの CSS 改善サイクルが回り始めた話 - Speee DEVELOPER BLOG
こんにちは、デジタルトランスフォーメーション（DX）事業本部のエンジニアの中嶋（@nyamadorim）です。もともと Rails のサーバサイド開発をメインに担当していましたが、今期はフロントエンド開発に取り組んでいます。 この記事では、「おうちの語り部*1」というプロダクトにビジュアルリグレッションテストを導入して、CSS の改善サイクルが回り始めた話を紹介します。 ビジュアルリグレッションテストとは ビジュアルリグレッションテスト導入の動機 テストツールの選定 reg-suit 他のテストツール reg-suit によるテスト環境の構築 reg-suit によるビジュアルリグレッションテストのフロー reg-suit の利用イメージ 差分が見つかれば、Pull Request に通知 どのページ/コンポーネントが変わったかを見る ピクセル単位で差分を確認する 差分がなければ ✨✨ R
React テスト応用、テストに悩む人へ
2022-05-06 更新 「React でコンポーネントテストを書くといいらしい、 React Testing Library や jest でサンプルを参考に書いてみたが 現実どうやってプロダクトコードに合わせていけばいいか分からない」 そういった方が対象となる本を目指しています。 いろいろ調べて実践したものの下記のように感じた方に適しているかもしれません。 - 結局テストで何を担保しようとしているか分からない - React のテストでハマっているか、Jest でハマっているか分からない - モックとかスパイとかアプリケーションとは遠い出来事も多くてピンとこない 誤り・ご指摘あればフィードバックいただけると嬉しいです。 無料で配布していますが、気に入ったらサポートなどいただけると今後もこの本をアップデートし拡張していく気持ちになれるのでよろしくお願いします。
System of a test: Proper browser testing in Ruby on Rails—Martian Chronicles, Evil Martians’ team blog
The Ruby community is passionate about testing. We have plenty of testing libraries, there are hundreds of blog posts on the topic, we even had a dedicated podcast. Hell, the top 3 most downloaded gems are parts of the RSpec testing framework! Rails, I believe, is one of the reasons behind the rise of Ruby testing. The framework makes writing tests as enjoyable as possible. In most situations, fol
ビジュアルリグレッションテストを導入した話 - メドピア開発者ブログ
こんにちは。フロントエンドエンジニアの小林和弘です。 Vue.js + Atomic Designでつくられたプロジェクトにビジュアルリグレッションテストを導入しました。 ビジュアルリグレッションテストでUIの安全性を高める コンポーネントの改修、新機能の追加、ライブラリのアップデートを行う際、UIに不要な変更が入っていないか不安になることがあると思います。リファクタリングをしようにも、意図しないところでUIが壊れないか心配になります。 画面表示に関わるコードを改修するたびに、ローカル環境やステージング環境で全UIコンポーネントを確認するのは難しいです。 また、ステージング環境と本番環境を並べて変更されたUIを目視で確認するのも非現実的です。 ビジュアルリグレッションテストはその名前の通り、視覚的な回帰テストを指します。改修前後のスクリーンショットの差分を検証するためのテストです。 開発に
テストの説明に安易に「正しく」とか書かない - Object.create(null)
みなさんテストは書いていますよね. 書いていなければふりだしに戻る. 例えば関数 add に対して, 以下のようなテストコードがあるとします. describe("add", () => { it("正しく計算できる", () => { expect(add(1, 2)).toBe(3); }); }); よさそうですね? もしよくないと思うのであればここから下は読まなくても大丈夫なくらい理解している方だと思います. 続いて関数名を変えただけのこちらをどうぞ. describe("sub", () => { it("正しく計算できる", () => { expect(sub(1, 2)).toBe(3); }); }); なんだか明らかに間違っている気がします. もしこのテストが通過してしまったとき我々はどうすればよいのでしょうか. 考えられるパターンは 2 つあります. 実装もテストも正
tsdでTypeScriptの型定義とテストで戦う
この記事はTypeScript Advent Calendar 2019 の 16日目の記事です。 「Mapped types」,「Conditional Types」などTypeScriptの型システムは高機能です。 しかし、高機能がゆえに複雑で直感的には分かりくい型を生み出していることも事実です。 TypeScriptの型定義は型を返す関数として扱うことができ、型がバグを生み出す原因にもなります。 そんな型でのバグをなくすために型のユニットテストを紹介します。
テストを書きたくない話 / I don't want to write tests
2019/10/11に行われた「「テスト」の話を聞いてみようの会」での登壇資料です
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
Automatically detect memory leaks with Puppeteer - Article by Christoph Guttandin - Media Codings
About half a year ago Bronley Plumb kindly made me aware of a memory leak in one of my open-source packages. To see this memory leak in action it was necessary to open a browser and its dev tools to execute some manual steps. On top of that, the memory had to be inspected manually. It was a complicated procedure. Normally I just add a failing test before I fix a bug. This time it was a bit more tr
デシジョンテーブルの解説 | ソフトウェアテスト・テスト技法に関する情報サイト
デシジョンテーブルとは デシジョンテーブルとは、決定表(JIS X 0125)[1]として規格が定義されています。論理関係を表形式で整理するためのツールで、行方向に条件と動作、列方向にルールの組合せます。プログラムの処理条件やポリシーなどをわかりやすく表現するために利用したり、ソフトウェアのテスト条件を整理するためにも利用されます。 図1. デシジョンテーブルの例（駐車場料金の割引計算） デシジョンテーブルを作成する手順は一般的に以下の通りです。 分析対象・テスト対象の持つ条件・原因を洗い出し、それぞれを行として追加します 処理・動作・結果を洗い出し、それぞれ行として追加します 起こりうる条件・原因の組合せを作成し、それぞれ列として追加します 作成した列のうち、集約可能な列の組を圧縮します 組合せの作成と圧縮についての検算をします デシジョンテーブルを使うことで以下のようなメリットが挙げら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
System of a test II: Robust Rails browser testing with SitePrism—Martian Chronicles, Evil Martians’ team blog
Visual testing & review for web user interfaces
クロスブラウザテストの闇と闇と闇
httpbin.org