mswjs/data で広がるテスト戦略
本稿は MSW（Mock Service Worker）エコシステムのうちの一つ mswjs/data を試してみた記事です。記事中のサンプルコードは以下で公開しています。 mswjs/data とは 仮想 DB をブラウザ（インメモリ）に展開する、データモデリング・リレーションライブラリです。MSW 単体ではハードコードされたフィクスチャのみの定義となりますが、mswjs/data を併用することで、データ駆動型 API モックを作成することが可能になります。使い始めは簡単で、以下の様にスキーマを定義しfactory関数で DB インスタンスを生成します。 import { factory, primaryKey } from '@mswjs/data' const db = factory({ user: { id: primaryKey(String), firstName: Str
jest における MSW の活用事例
MSW を使った jest のテストについて、引数などの検査が面倒という記事を拝見したので、もし同様にアプローチを模索されている方がいらっしゃれば参考に、と思い記事にしました。筆者は普段以下の様に、server.use内にjest.fnを仕込みテストしています。例えば API が2回呼ばれたことを検証する場合、次の様になります。 const server = setupMockServer(...handlers); describe("API call の検証", () => { const mockFn = jest.fn(); beforeEach(() => { server.use( rest.get("/path/to/api", async (req, res, ctx) => { mockFn(); // <- here return res(ctx.json({}));
Next.js 12 x React 18 について調べたメモ
'RSC'.reverse() == 'CSR' 現状公開されている情報から、Edge Functions を起点に Component を Streaming することが Vercel x Next.js x React 18 のゴールに見える。Edge Functions で RSC(React Server Components) を SSR するメリットは以下の様に考えている。 物理的に近い Edge サーバーなので速い V8 Isolete 実行環境のため立ち上がりの速い（Node 依存の Serverless より速い） CSR と比較しラウンドトリップが少ない このPR で Next.js に Server Components を導入した Shu Ding 氏がピン留めしている以下ツイートは必読。
テスト優先度をあげたくなる実話 - フロントエンド版 -
Storybook・テストに関して「メンテナンス工数に見合うだけのメリットがあるか？」という議論を、経験したことはないでしょうか。フロントエンドは、とにかく動くものを作ることが優先され、Storybook・テストが二の次になっている現場も少なくないと思います。 限りある工数を割きチームで取り組むものですから、導入するためには「どういったメリットがあるのか？」という具体的な例をチームに示す必要があります。これは今年、筆者が体験した実メリットのお話です。導入を躊躇している現場にむけ、参考になればと思い書きました。 【Storybook】不要な Global CSS を削除できた きちんとコンポーネント設計され、コンポーネントに閉じた指定をしていたとしても、どこかに必ず Global な CSS があると思います。何かしらの資材を受け継ぎ立ち上げたプロジェクトに関しては、Global な CSS
Next.js の Error を丁寧に扱う
Next.js には組み込みのエラーフォールバック機構が存在します。pages/404.tsxとpages/500.tsx、Unhandled Error を捉えるpages/_error.tsxが組み込みフォールバックです。https://nextjs.org/docs/advanced-features/custom-error-page 実アプリケーションにおいてはこれだけでは不十分なケースが多く、意図的なもの・そうでないものをハンドリングしログ収集に繋げるなど、きちんとエラー設計をしたいところです。 TypeScript 4.4 で try catch の推論が変更になった 話が少しそれますが、TypeScript 4.4 で try catch 文の catch 引数errの推論がanyからunknownに変更になりました。この変更はuseUnknownInCatchVariab
openapi-generator-cli による TypeScript 型定義
openapi-generator-cli を利用すると、OpenAPI 定義から TypeScript で利用可能なアセットを生成することができます。しかし最適な成果物を得るためには、OpenAPI 定義自体に少し工夫が必要で、一筋縄にはいかないことがあります。 本稿及びサンプルリポジトリでは、openapi-generator-cli と TypeScript 4.2 の新機能を活用したアプローチを紹介します。 課題点の確認 OpenAPI 定義にあたりresponsesフィールドのschemaに対し、インラインで定義を追加することが多いのではないでしょうか？OpenAPI を定義する GUI 「Stoplight Studio」 などでは、このインラインスキーマ定義が直感的で使いやすく、yaml を直接編集しなくても良いなど、開発に重宝します。 responses: "200": d
React.Context で作る GlobalUI Custom Hooks
GlobalUI を、React.Context を利用して作る TIPS です。どの Component からも利用しやすい様に Custom Hooks を経由します。何かを更新した際、画面上部に通知を表示する（Notification）よくあるサンプルを元に解説します。（↓ の画像の様なもの） Custom Hooks 利用例 Notification を呼び出す Component は次の様なコードになります。showNotification関数に任意の文字列を与え表示する、というシンプルな作りです。 export const Example = () => { const { showNotification } = useNotificationDispatch(); const handleClick = () => { showNotification("更新しました");
hygen で生成 - 対話形式の Component 雛形 -
Component 作成にあたり、storybook や test も一度にコミットする場面が増えてきました。そして CSS Modules や、特定 Component 専用の custom hooks など、一つの Component を構成するファイル群はそれなりの量になってきます。例えば、以下の様な module 構成の Component です。これを手作業で作成するとなると、少し億劫になりますよね。 └── atoms └── Button ├── Button.stories.tsx ├── Button.test.tsx ├── Button.tsx ├── dependencies.ts ├── index.tsx └── style.module.css 作成時にButtonという名称だけ決めてしまい、CLI から雛形出力できれば、作業効率向上が見込めます。（story
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Storybook CSF3.0 時代のテストに備える