Vue Fes Japan 2024のLTの資料です
動機 cdk プロジェクト(TypeScript)は立ち上げたときに jest(ts-jest)を使う形で自動テストの雛形が自動セットアップされている。 基本それをベースに改修していく形で困らない。 が、ts-jest は実行が遅かったりする。型チェックをしてくれるというのはあるが、cdk におけるテストでは恩恵はあまり多くない気もする。 TypeScript を利用する cdk プロジェクトではビルドに esbuild が使われるため、速度が問題であればesbuild-jestを使う手もある。が、執筆時点における最終アップデートが 2021 年 5 月だったりとメンテナンスが頻繁でなく心許なかったりする。 そこで、vitestを使ってみる。 検証環境 Fedora37 node v18.15.0(LTS) pnpm@8.1.1 あまり本質ではないが今回はパッケージマネージャーに pnpm
この記事について サービス開発統括本部 ソリューション開発部で農業プロダクトの開発を担当している西村です。 弊社でピンポイントタイム散布(以下、PTS)という防除のデジタル化サービスを展開しております。 PTSでは農地のデータを管理するため、Google Maps APIの活用は欠かせません。そのコアな技術を活用した処理は品質を担保する必要があります。 また、PTSはVue3系で開発しており、ビルドツールにはViteを使用しております。ViteはVue3系推奨されています。 そこで今回は、Viteを利用したテストフレームワーク、Vitestを使ったGoogle Maps APIのテストコードについて紹介します。 先に結論を3つ VitestとはBlazing Fast Unit Test Frameworkとドキュメントに記載されている通り、とても処理が早いユニットテストフレームワークのこ
こんにちは。ナレッジワークの torii です。 7 月にフロントエンドエンジニアとして入社してもうすぐ半年、そろそろ技術記事の一つも書きたいなと思っていたところに、ちょうどいいネタを見つけたので投稿してみます! Jest から Vitest に移行してみた 早速やったことですが、フロントエンドのテストフレームワークを Jest から Vitest に移行しました。理由としては、Jest が CJS を前提として動作しており、ESM 前提のモジュールを動かすのに一手間も二手間もかかるからです。 ナレッジワークのフロントエンドは Next.js を採用しており、テストフレームワークには Next.js と相性の良い Jest を採用していました。関数単位のテストや UI コンポーネントのテストを書く分には問題なかったのですが、それより上層(ページなど)になるとたちまち ESM 互換性の問題を
1. はじめに Playwright編で調べていた時に、Vitestでも同じようにUIでテスト周りを確認できる機能があったため、 追調査として今回はVitest UIを調べてみました。 前回、Playwrightで調べた背景をおさらい 近年、フロントエンド開発においてコンポーネントテストの重要性が高まっています。 私が携わっているプロダクトでも以前より、フロントエンドの単体テストおよび統合テストを導入しており、私も作成したフロントのコードに対してテストを実装していました。 しかし、コンポーネントテストや単体テストを書いていく中で、いくつかの個人的な課題に直面しました。 特に大きな問題となったのは、テストの動作を視覚的に確認できないことによる不安です。 具体的にはプロダクトでテストを記述している中で問題がありました。 テストコードで対象の要素が取得できず、テストを実行できない場合がある 要素
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く