【読書】Unit Testing Principles, Practices, and Patterns 感想 「テストは分類器」であるととらえ、混同行列における偽陽性を取り除くことが、単体テストで注力すべき柱であるという視点が得られたのが大きい。偽陰性を出さないことも重要ではあるが、プロジェクトの持続的な成長の観点からは偽陽性を出さないようなテストを書くことが最も重要である、と意識するだけでもテストの書き方は変わる。どうすればそのようなテストを書けるのか？という疑問にも答えが示されている。 数学的な背景のある著者は、プログラミングのガイドラインは数学的な定理と同様に第一原理から導出されるべきであるとの立場に立っており、本書は一貫して根本的な問いから徐々に論拠を構築して、最終的な結論に至るようなボトムアップ式の展開となっており、非常に理解しやすく腑落ちするところが多かった。 単体テストや統

Playwrightあるいはそのロケーターの元ネタとなっているTesting Libraryでは、DOMを指定する方法として data-testid 属性を扱ったクエリーを提供しています。どちらでも getByTestId(ID文字列) メソッドを使い、この属性値を使った要素の取得が行えます。しかし、ドキュメントを見ると、PlaywrightもTesting Libraryも、「他の手法が使えないときの最終手段」としています。 In the spirit of the guiding principles, it is recommended to use this only after the other queries don’t work for your use case. Using data-testid attributes do not resemble how your

はじめに 今回紹介するのは、React や Vue などの「コンポーネント指向のフロントエンド開発」における「テスト方針の考え方」と、それを実現するための「方法論」です。 初めて React などのコンポーネント指向のテストを書くとき、どういう考え方・方針でテストを書いていくのか分からず悩んだ人も多いのではないでしょうか。 この記事ではその疑問の1つの解として、React 公式で推奨されているテストライブラリ Testing Library の開発者であり、Testing Trophy というテストコンセプト考案者でもある Kent C. Dodds の考え方とその実現方法を紹介していきます。 社内のシステムでも実際にこの Kent のコンセプトに従いテストの運用をしていますが、これによって「壊れにくいテスト」がフロントエンド（React）で書きやすくなっています。より正確に言うと「壊れる

https://offers.connpass.com/event/299909/ 登壇資料

ソフトウェアテスト・ 品質保証 セキュリティ UI/UX DX カスタマーサクセス コンサルティング Our Services サービス ソフトウェアテスト・品質保証

2023年6月27日に開催されたFLEXY meetupのテーマは「フロントエンドのテスト」です。 技術の進化とともにバックエンドとフロントエンドが疎結合になる今、フロントエンド領域ではテストの重要性が高まっています。 一方、現場レベルではテストコードを書いたことがなく、何から始めるべきなのか悩みを抱えているエンジニアは多いのではないでしょうか。 そこで今回は、実際にフロントエンドのテスト導入を行っている古川さん、nus3さんの2名がディスカッション。「フロントエンドテストはじめの一歩」として今、何ができるのかを実例も交えながら教えていただきました。 イベント概要 技術の進化に伴い、アーキテクチャレベルでバックエンドとフロントエンドが疎結合になった今、フロントエンド領域におけるテストの重要性について注目が集まっています。 一方でまだ手法が広まっておらず実際にテストコードを書いたことがないた

ここから下で話す際、主に使う言語・フレームワーク・ツールとしては - Typescript - React (Next.js) - Jest - React Testing Library - ブラウザテストツールとしてPlaywright を前提としています。ただ話す内容の本質的な部分はVueでもSvelteでも、Vitestだろうがあまり変わらないだろうなと思ってます。そう思って見ていただけると助かります。 現代ではReactでUIの単体テスト・インテグレーションテストを書く場合、Jest x React Testing Library を使うのが一般的かと思います。皆さんはJestでUIテストを書いていますか？Jestでコンポーネントの単体テストを書いていると辛いことがたくさんありませんか？例えば 大量のライブラリのモックによる(これってテストやる意味あるの・・・？)と感じる虚無感

はじめに 新規開発のプロジェクトでテスト戦略を立ててしばらく開発をしています。そのテスト戦略の内の 1 つに Web API モックの運用ポリシーを決めていたのですが、大きな問題がなく運用ができているので「API モック戦略」と大袈裟に題してみました。 特に奇抜なことはしていないですが、振り返りとしてまとめたいと思います。 目的 Web フロントエンドの開発時にモック API を利用して動作確認・自動テストをしたい 開発サーバを起動するだけでブラウザで動作確認をしたい Testing Library などを用いた UI コンポーネントの振る舞いを自動テストしたい モックデータの管理を簡単にしたい ブラウザでの動作確認と自動テストで同じモックデータを利用したい 前提 API のモックサーバは Mock Service Worker （以下 MSW と呼ぶ）を利用する。MSW のメリットや利用

概要 こんにちは、Offers を運営している株式会社 overflow のバックエンドエンジニアの shun です。今回は、Datadog Synthetics 上でブラウザテストを作成する際に利用できる Subtest についてご紹介します。 Datadog Syntheticsとは？ Datadog という SaaS の一機能で、主にブラウザテストを GUI で作成し、定期実行 or CI 経由の実行を可能にしてくれるものです。 ブラウザテストの作成を大量に行う際、当然メンテナンスコストもかかってきますが、今回ご紹介する Subtest を用いると、比較的メンテナンスがしやすい形になります。 Subtestとは？ 簡潔にいうと、一度作成したブラウザテストを他のテスト上でも使い回せるようにComponent化できる 機能です。フロントエンドのように Props 設計なるものは考慮不要で

Jest reporter English | 简体中文 Jest test results processor for generating a summary in HTML Example page https://hazyzh.github.io/report.html Installation # yarn yarn add jest-html-reporters --dev # npm npm install jest-html-reporters --save-dev Usage Configure Jest to process the test results by adding the following entry to the Jest config (jest.config.json):

皆様フロントエンドのテストを書いていらっしゃいますでしょうか？ フロントエンドのテストを書くときには API コールする処理を全てモックする必要があります。外部の API をコールする処理をテストに含めると API サーバーが落ちているなどの外部の要因によってテストが失敗してしまう可能性がありますし、テストを実行するたびに実際に API をコールしてしまうとサーバーに負荷がかかってしまうなど外部に対しても悪影響を与えてしまいます。 さて、従来のモックする手段としては Jest のモックを利用して axios や fetch などのモジュールをモック化する手法がよく使われていたかと思います。 最近のテスト手法として API コールをモックする際に Jest ではなく Mock Service Worker (以下 msw ）を使用する手法が注目されています。実施にどのように使用されているのか

日々いろいろなWebサイトの制作や修正を対応していく中で、修正したページとは関係ない（と思っていた）ページで表示が崩れてしまったことってありませんか？ 私はたびたび経験があります。 毎回目視で全ページをチェックすれば防げるのかもしれませんが、それは現実的ではありません。 自動で全ページをチェックしてくれて不具合があれば教えてくれる、そんな便利なツールがあればと何度も思いました。 どうやら現代の技術でそれは作れるみたいです。ビジュアルリグレッションテストというらしいです。 ビジュアルリグレッションテストとは ざっくりいうと「見た目の比較」をするテストのことです。 変更前のWebサイトのスクリーンショットを用意しておき、変更後のスクリーンショットを撮り比較することで、どこが変わったか差分を表示し確認することができます。 どうやって使うの ビジュアルリグレッションテストを導入するための方法はいく

(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事

Common mistakes with React Testing LibraryMay 4th, 2020 — 15 min read Hi there 👋 I created React Testing Library because I wasn't satisfied with the testing landscape at the time. It expanded to DOM Testing Library and now we have Testing Library implementations (wrappers) for every popular JavaScript framework and testing tool that targets the DOM (and even some that don't). As time has gone on,

こんにちは。自称 Kent C. Dodds ファンの梅津です。 最近はまっていることは Kent のブログを読み漁ることです。 これは Kent C. Dodds が書いた Testing Implementation Details を翻訳したものです。 kentcdodds.com Enzyme のテストの辛さ 実装の詳細をテストすることの弊害 Testing Library による解決方法 などが解説されています。 また、最後の方に「テストは何のために、誰のために書くのか？」が語られているのですが、いやーこれが本当に深い！ 元の記事が書かれたのは 2018 年ですが、とてもいい内容だったので今更ながらまとめてみました。 皆さんも是非読んでみてください。 Testing Implementation Details 実装の詳細をテストすることは災いの元です。 なぜそうなるのか？そして

ソフトウェアテストシンポジウム 2020 新潟 JaSST'20 Niigata 基調講演 2020年9月28日（月） http://www.jasst.jp/symposium/jasst20niigata.html

はじめに ソフトウェア開発のチームの生産性や健全性というものは、内部の体感的として理解できるものの、外部の人間からは見えにくいものです。こういった情報の非対称性は開発チーム外の人々との関係の中での問題の原因になってきました。 また、複数の開発チームやプロダクトを束ねるEM、CTOや、管理職にとってそれぞれの状況を客観的な数字やグラフで可視化することは、全体的な戦略を考える上でも重要な参考情報になります。ですが、アンケートやプロジェクト管理を増やすほど、どんどんと開発メンバーに負担をかけてしまうことになり、計測のし過ぎによる疲れなども誘発してしまいます。 本稿では、gitリポジトリのログ情報から、いくつかのグラフを生成し、チームの状況を可視化するためのツールgilotを作成したので、その目的と意図、そして使い方、注意点を解説します。 アプローチ方法 gilotのアプローチは、git logの

bugspotsについて igrigorik/bugspots グーグルのバグ予測アルゴリズムを実装したツール「bugspots」について グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開 － Publickey 上記記事が参考になります。 面白そうだし、品質あがるのであればやってみたい、やってみよう。 やってみるぞ 導入の仕方は、READMEに書いてある通りで動くので割愛。 実行。go。 $bugspots . Scanning . repo Found 1234 bugfix commits, with 1234 hotspots: Fixes: - fix a comment - Fixed index hogehoge Hotspots: 0.8875 - Gemfile.lock 0.8478 - Gemfile 0.7712 - app/

「究極的には、QAチームは無いのが理想」と言い切るグロービスQAチームが少数精鋭で挑むチャレンジをご紹介します。アジャイル開発の品質のあり方、そして理想に至る短期・中期・長期のゴールとは？ 結論ファーストはじめに、本エントリーの要約を載せておきます。 スピードの速いアジャイル開発において、もはや品質はQAエンジニアやQAチームだけが保証するものではありません。企画からリリースまで関わるチーム全体で創り上げていくものなのです。ビジネス価値向上への貢献を使命とするグロービスQAチームは、開発チームから独立した立場でスピードと品質を両立すべく工夫したテストはもちろん、データドリブンの品質改善活動や、SM・POやステークホルダーへのアプローチを通じた上流からの品質向上および組織の品質文化醸成に取り組んでいます。QAチームがいなくても高品質のプロダクトが素早く提供される組織こそが、グロービスQAチー