Storybook 駆動開発 @ CSF3.0
Storybook CSF3.0 の概要 単体テスト・結合テスト・Storybook を充実させるためには、多くの工数が必要です。堅牢なフロントエンド開発のためとはいえ、これらのメンテナンスは日に日に負担が増しています。似かよったテストケースでは、同じような下作業をそれぞれに用意する必要がありました。 Component Story Format（CSF）は、この課題への取り組みとして開発されました。「様々なソリューションで再利用可能な資材」 が用意できれば、開発は素早く・より楽しいものになります。リリース間近の CSF3.0 はより一層、そのゴールを明確に示してくれています。 testing-library で Story にインタラクションを CSF3.0 新機能の中で際立っているものが play 関数 です。@testing-library/user-eventを利用すると、Stor
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 の
Storybookを導入する際にやるべきこと3選
Storybookがバージョン7がリリースされたため、加筆、修正しております。 またコードジェネレーターとしてhygenを推奨していましたが、追記当時2023/05時点ではPlopを推奨します。 理由は、PlopはESM対応が自然とできるからです。 はじめに フロントエンドエンジニアとして活動するとおそらく耳にするであろうStorybook。 その有用性が語られることもあれば、時に悪名も耳にすることもあるかと思います。 Takepepeさんが以下のような"あえてStorybookを使わない理由はなんですか"というアンケートを取られておりました。 結果は、「面倒・メンテナンスコストが高い」でした。 実際に私も先輩に、メンテナンスコストが想像より辛く、いいものではなかったと言われたことがありました。 ですが、私は担当したプロジェクトでStorybookの導入に踏み切りました。 それは、これから
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Storybookを書くだけでリグレッションテストが 実行される世界へようこそ
Storybookを用いてテストの可視化を進めた話 | PR TIMES 開発者ブログ
