私のフロントエンドディレクトリ構成・テスト観点 2022
近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します（あくまで執筆現在の脳内アウトプットになりますのでご了承ください） フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの？」と思うこともあるので、とくに要望がなければ、筆者は「
実装例から見る React のテストの書き方 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは！フロントエンドエキスパートチームの@nus3_です。 kintone のフロントエンド刷新プロジェクト（フロリア）では、品質を保ったまま開発を加速させるためにフロントエンドのテストを積極的に行っています。 今回はそんなフロントエンドのテストの実装例をいくつか紹介します。この記事がフロントエンドのテストを行う上での参考になれば幸いです。 テストに使用する主なパッケージ コンポーネントのテスト 補足: Testing Library の記法をチェックしてくれるeslint-plugin-testing-library カスタムフックのテスト 補足: React v18 では @testing-library/react の renderHook を使う 参考リンク 色々なテスト事例 setTimeout を使うコンポーネントのテスト 補足: Storybook の story を使
AtomicDesign の仕分けをテストで判定する
AtomicDesign には「Atoms か Molecules か？、Molecules か Organisms か？」の判定が悩ましい…という課題があります。これは、フロントエンド・デザイナー間ではもちろん、デザイナー同士でも解釈差異があるようです。明確な判定軸がなければ、いずれブレが生じ、規律のないデザインシステムになりかねません。 この状況に対し「アクセシビリティを軸にする」という発想に至り、どのように仕分けるかを先日の投稿で紹介しました。このアイディアはタイトルのとおり「テスト」で機械的に判定可能です。 AtomicDesign カスタムマッチャー関数 「AtomicDesign の仕分けをテストで判定する」ために、独自のカスタムマッチャー関数を設けます。普段利用している'@testing-library/jest-dom'もカスタムマッチャーのライブラリですが、このカスタムマ
a11yとテストを同時に改善する話
これまで、a11y 改善・テスト拡充にあたり「どのように改善すべきか？どのように書くべきか？」という点がハードルだと感じていました。Chrome で a11y tree を確認するには、dev tools の隅の隅をつつく必要があり、あまり体験の良いものではなく、気に入ったエクステンションもありませんでした。 Testing Library は「誰もがアクセスできるクエリー」を優先的に使用することを推奨していますが、アプリケーションがはじめから a11y に考慮された作りになっているとは限りません。これらの背景から「data-testid」のような、テスト向け属性に頼るワークアラウンドで乗り切ることも少なくありませんでした。 Full page accessibility tree 今年 1 月にリリースされたChrome98 の新機能として「Full page accessibility
GitHub - httptoolkit/mockrtc: Powerful friendly WebRTC mock peer & proxy
Let's write an automated test with MockRTC. To test WebRTC-based code, you will typically need to: Start a MockRTC mock session Define rules that match and mock the traffic you're interested in Create a WebRTC connection to a mock peer, by either: Using MockRTC's offer or answer directly. Applying the provided MockRTC.hookWebRTCConnection hook function to your RTC connection, and then connecting t
TypeScript 3.7 の Assertion Functions 注意点 | La Verda Luno
Announcing TypeScript 3.7 Beta に “Optional Chaining” と “Nullish Coalescing” という待望の機能とともに “Assertion Functions” が登場しています。 これは従来からある User-Defined Type Guard と似ていて、こちらは条件に合わない場合に例外を投げるような、別言語での assert 構文・関数と似たものを TypeScript のフロー解析に入れる機能追加です。 Assertion Functions については TypeScript 3.7の asserts x is T 型はどのように危険なのか が全体的に詳しいです。 この投稿の本題は、それの制約に関するメモです。 Assertion Functions を使ってトリッキーなことをしようとして阻まれたわけですが、日本語の記事
Puppeteerによるフルページスクリーンショットを画像遅延読み込みに対応させる - DeNA Testing Blog
こんにちは、薦田です（@toshiya_komoda）。 今回はChromeブラウザのブラウザテスト自動化ツールであるPuppeteerに関するTipsを紹介します。 Puppeteerによるフルページスクリーンショット Puppeteerは、Chrome DevTools ProtocolのNode.jsクライアントであり、Chrome DevToolsチームがメンテナンスしています。 その主な用途の1つにブラウザ自動テストが挙げられます。 PuppeteerはChromeの操作に特化しており、操作対象がChromeに限定されるもののSeleniumにはない便利なAPIを利用できます。 Puppeteerで利用できる便利なAPIの1つに、フルページスクリーンショットがあります。 フルページスクリーンショットとは、ウェブページの上端から下端までを1つなぎの画像としてスクリーンショットを撮っ
An Overview of JavaScript Testing in 2020
(Updated on: 21.11.2021) This guide is intended to catch you up with the most important reasoning, terms, tools, and approaches to JavaScript testing for the year 2022. It combines information from the best articles recently released (they are referenced at the bottom) and adds from my own experience. It’s a little long but whoever reads and understands this guide, can safely assume they know the
TestCafeでブラウザの自動テスト(E2Eテスト)
TestCafeという自動テストフレームワーク(いわゆるE2Eテストフレームワークジャンルとしておきます)を試してみました。 TestCafeの特徴としては、Seleniumを使っていないこと、設定ファイルなしで利用できる点です。 Seleniumを使ったテストフレームワークとしては、Protractor、testium、WebdriverIOなどがあります。 (Seleniumを使わない他のテストフレームワークだとNightmareなど) Seleniumを使わずにどうやって自動的にブラウザを操作するかというと、中継サーバーを起動してそこにテストコードなどを追加して動かすことができるSelenium RC(1)方式に近いものだと思います。 同名のウェブサービス/クライアントアプリも出していて、こちらはSelenium IDEのようにGUIで操作して記録したものを再生などができます。 なぜ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
