Web フロントエンドのテストと持続可能な方針の組み立てを考える | Offers Tech Blog
Offers を運営している株式会社 overflow の あほむ でございます。 今回はプロジェクトで Web フロントエンド領域のテストを書くにあたって方針を決めた際の ADR をブログ向けに再整理したものをお届けします。 テストコードを書くべきか書かざるべきか 逃げ切りが確約された作り捨ての納品プロジェクトでもなければ、継続的なメンテナンスを前提にテストコードは書くべきが現代のソフトウェアエンジニアにおける共通了解でしょう。 急がば廻れ、ほとんどの場合においてテストコードを書くメリットがデメリットを上回るものと捉えられています。ここでは書かなくても良いケースをあえて論じることをしませんが、個別具体でテストが不要と断定できるときはそうすればよいでしょう。 テストを整える工数をどう捉える TDD (Test Driven Development テスト駆動開発) に代表される、テストコー
Storybook Test ruuner で安定した Visual Regression Testing を行う
はじめに 株式会社ナレッジワーク Engineering Division のわだまる（@wadackel）です。 ナレッジワークの Web フロントエンド開発では、Storybook を活用したコンポーネント開発を行っています。そして、昨年末により良いコンポーネント開発の基盤整備を進めるべく @storybook/test-runner（以降 Storybook Test ruuner）を導入しました。導入目的としては主に、各 Story に対するスモークテスト、play 関数を活用したコンポーネントテストを行うことです。 さらに、ナレッジワークでは前述した通常のコンポーネントテストに加えて、reg-suit と storycap を利用した Visual Regression Testing（以降 VRT）を行っています。 これまでは Storybook を活用したテストは VRT の
フロントエンドの書くべきだったテスト、書かなくてよかったテスト
https://offers.connpass.com/event/299909/ 登壇資料
t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
モックは必要悪で、しないにこしたことはない - blog.8-p.info
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
Webフロントエンドのための実践「テスト」手法 CodeZine Night #1
CodeZine編集部主催のウェビナー「CodeZine Night」の第一回発表資料 https://codezine.connpass.com/event/279012
How to Test React.useEffect
So, you've got some code in React.useEffect and you want to know how to test it. This is a pretty common question. The answer is kinda anti-climatic and general. Here's how you think about testing anything: How does the user make that code run? Make your test do that. That's it. That's the secret. The trick is discovering what constitutes a "user." Your React components actually have 2 users: the
Storybookのテストランナー
はじめに Storybook test runner turns all of your stories into executable tests. https://github.com/storybookjs/test-runner Storybookの全てのStoryをテスト可能にする@storybook/test-runnerについてのメモ。 Storybookの公式ドキュメントではv6.5からテストランナーについてのページが設けられている。 何をテストするものか テスト対象についてはplay関数の有無によって異なる。 For those without a play function: it verifies whether the story renders without any errors. For those with a play function: it also
Storybook for full-stack developers
Full-stack developers are responsible for everything from writing CSS to wiring up databases. This involves a lot of context-switching and dealing with side-effects from different parts of the stack, which can end up slowing you down. Storybook helps developers focus on the UI layer of the stack. It runs alongside your app and provides a sandboxed environment for visualizing, developing and testin
Storybook 駆動開発 @ CSF3.0
Storybook CSF3.0 の概要 単体テスト・結合テスト・Storybook を充実させるためには、多くの工数が必要です。堅牢なフロントエンド開発のためとはいえ、これらのメンテナンスは日に日に負担が増しています。似かよったテストケースでは、同じような下作業をそれぞれに用意する必要がありました。 Component Story Format（CSF）は、この課題への取り組みとして開発されました。「様々なソリューションで再利用可能な資材」 が用意できれば、開発は素早く・より楽しいものになります。リリース間近の CSF3.0 はより一層、そのゴールを明確に示してくれています。 testing-library で Story にインタラクションを CSF3.0 新機能の中で際立っているものが play 関数 です。@testing-library/user-eventを利用すると、Stor
Next.js アプリケーションの共通コンポーネント開発 - クックパッド開発者ブログ
こんにちは。レシピサービス開発部のkaorun343です。クックパッドではスマートフォン向けページにおける開発者体験向上のために、レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話にて紹介したとおり、Next.jsとGraphQLを用いたモダンな環境へと移行を進めています。例えばモバイル端末からのアクセスでURLがトップページの / であれば Rails、レシピ詳細ページの /recipe/:id であれば Next.js アプリにルーティングされるようになっています。現在ではレシピ詳細ページだけではなく検索結果ページやつくれぽ詳細ページ、MYフォルダページなどもNext.jsアプリケーションに置き換わっています。今回はその移行により生じた課題と取り組み方、それから併せて実施したモノレポ環境整備について紹介します。 共通コンポーネントの導入背
ぼくたちがかんがえたさいきょうのStorybook 〜より高品質なコンポーネントを求めて〜
この記事は、Money Forward Engineering 2 Advent Calendar 2022の20日目の投稿です。 21日目の記事は、Taiga KIYOKAWAさんによる『react-i18next で日本語の改行箇所を制御したい時は、設定で wbr タグを使えるようにしよう』でした。 本日は、マネーフォワードに入社して3ヶ月目の私が、「コンポーネントを高品質に保つためのStorybook運用」というテーマで、記事を書いていきます👊 背景 私が開発に携わっているプロジェクトでは、マネーフォワードクラウドにある複数のプロダクトを横断して利用される機能を開発しており、その機能をマイクロフロントエンドとしてプロダクト側に提供しています。 より詳しく知りたい方は、Money Forward Engineering 1 Advent Calendar 2022の14日目に投稿され
Common mistakes with React Testing Library
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,
フロントエンドのテストコードを書くときに大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームの @mugi_unoです！ kintone では フロントエンドの刷新プロジェクト（通称フロリア）が進行中です。 blog.cybozu.io kintone の開発では E2E 主体の自動テストを整備していましたが、 フロントエンドの刷新に合わせて、新たにフロントエンド側でのテストコードを積極的に書いています。 テストを書くことに不慣れなメンバーもいるため、日々 Pull Request 上でのレビューやペア・モブ作業を通じて、知見の共有が行われています。今回はフロントエンド刷新のテストを書いてきた中から、筆者が有用だと感じた知見やノウハウを紹介したいと思います。 目次 💡「実はそれ最初からパスしてるかもしれない」 期待する操作で期待する結果になることを厳密に検証する 他のテストケースによって前提条件を担保する 💡「テストコード上のロジッ
Testing with Next.js
先日、Next.js におけるテスト手法について、公式ドキュメントが追加され話題になりました。 取り上げられている 2 者はよく知られており、いずれかに触れたことがある方も多いかと思います。この公式ドキュメントページでは「何を使って」を紹介しているのみなので、どちらを選ぶべきか悩んだ方もいるのではないでしょうか？ Cypress Jest & React Testing Library この判断についてはドキュメントに書かれていなかったので、筆者なりの見解を紹介していきたいと思います。 お勧めは「Jest & React Testing Library に寄せる」 Cypress は GUI が素晴らしく、テストを書く環境としてはとても体験が良いです。しかしテストが増えていくにつれ、以下のような点で DX 低下を招くことがあります。 CI の実行コストが高く、実行時間が長い cypress
Testing JavaScript with Kent C. Dodds
Learn the smart, efficient way to test any JavaScript application.—Your essential guide to flawless testing— Why bother testing your JavaScript?When a user encounters a bug they look like this: 🤬 Bugs grind work to a halt. Bugs cause financial harm. Every single time a bug is encountered, user trust erodes. Bugs are bad. And who gets blamed? You. The developer. You know you should squash bugs bef
React の テスト方針を調べた
今回は「Reactでテスト環境を作ろうっ！」と思ったのですが、そもそもReactのテストってどうするの？どんなツールを使うの？ということで、まずはReactのテストについて調べてみました。 Reactのテスト Vitest Vue.jsやViteの開発者が作っている高速で動作するテスティングフレームワークです。 2022年2月16日現在 v0.3.5でまだ開発版です。 GitHubにも「免責事項：Vitestはまだ開発中であり、安定したものではありません。実運用での使用はお勧めしません。」とあります。・・・残念😭 Jest + React Testing Library Reactの公式サイトによると Jest + ReactTestingLibrary が推奨のようです。 JavaScript テスティングフレームワークです。 React コンポーネントをテストすることができるツールセ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サバンナ便り〜自動テストに関する連載で得られた知見のまとめ〜
Component testing in Storybook
StorybookのUI Testing Handbookを読んだ
