【入門】フロントエンドのテスト手法まとめ - Qiita
はじめに 自分は2021年に新卒でweb系の開発会社にフロントエンジニアとして入社し2022年で2年目になります。 実務ではReact×TypeScriptを利用したフロント周りの開発をメインで行なっていなす。 今回は実務でNext.jsプロジェクトにテストを導入することになり「React-Testing-Library」と「Jest」について改めて学び直したのでその内容を紹介します。 はじめに「React-Testing-Library」と「Jest」の概要を説明しその上で具体的なテストコードを何パターンか書いていきます。 この記事の対象者 フロントエンドのテストの概要を知りたい人 React-Testing-LibraryとJestについて知りたい人 具体的なテストの書き方を学びたい人 なお本記事では、React-Testing-Libraryの具体的な書き方についてをメインにしている
フロントエンドにおける「単体テストの考え方/使い方」
本稿における「単体テスト」とは自動テストにおける単体テストを指します。手動テストのことではないので、ご了承ください。 単体テストの考え方/使い方という本を読みました。筆者自身、「単体テストはプロダクションコードの付属」という意識がどこかにありました。この本を読んで、単体テストについてあまりに何もわかってなかったことに気付かされ、単体テストの設計はプロダクションコードの設計と同じくらい重要という意識に変わりました。何のために単体テストをやるのか、いいテストとは、「単体」とは、など多くの点で学びを得られ、また、多くのプラクティスとアンチパターンを知ることができました。 本稿はこの本を読んで得られた学びを、フロントエンド開発、特にコンポーネント開発に適用することを試みた際のまとめです。より詳細な解説を求む方には本を手に取ってもらう前提で、できるだけポイントを抑えられるようにまとめることを目指しま
フロントエンドのテストは皆のためのもの | POSTD
テストとは人によって反応が分かれるものの1つであり、大喜びする人もいれば、見ないようにして去ろうとする人もいます。あなたがどちらの側であるにせよ、ここではフロントエンドのテストは皆のためのものであるということを説明します。実際、テストには多くの種類があり、それがテストに対して初めに恐れや混乱を感じる一因なのかもしれません。 この記事では、特に有名で広く利用されている種類のテストを扱います。なかには目新しいものはないと感じる読者の方もいらっしゃるかもしれませんが、少なくとも復習にはなるでしょう。どちらにせよ、筆者の目標は、この記事を通じて世の中のさまざまな種類のテストについて理解を深めてもらうことです。ここではユニットテスト、統合テスト、アクセシビリティテスト、ビジュアルリグレッションテストなどを一緒に見ていきます。 さらに、Mocha、Jest、Puppeteer、Cypressなど、各種
Sentry で JavaScript ランタイムエラーを監視してみて
月間 Issue 数は 2022 年 6 月から記録を残しているので、それ以前のデータがない。本当は 2023 年も 6 月のデータが欲しい.. また、このアプリケーションは、10 月から年末に向けてユーザー訪問数が増加する傾向があるので、12 月はエラーイベントと Issue 数が多くなっています。また、PR のタイミングで突発的に大きく訪問数が増えることもあります。この様な性質のアプリケーションなので、エラーイベント数は増減が激しく新しいエラーが発生しているのか、単に訪問数が増えたことによってエラーイベント数が増えているのかを見極めにくいので、Issue 数を減らすことを特に重視して取り組みました。 この記事では、Sentry の Issue を減らすために取り組んだことや決めたことを、書いても問題無さそうな範囲で記載しています。技術的な内容よりは、チームで取り組むためのルールだったり
Sentryで始めるエラー監視
はじめに そもそもSentryとはエラーの可視化、監視ツールです。ダッシュボード上でエラー発生時のスタックトレースや、リクエストデータなどを確認することができます。 こんな感じでエラーが可視化されます。 パフォーマンス監視ツールとしての機能も持ちますが、今回の導入目的からは逸れるので言及しません。 以下で紹介するSentryの機能を利用するためには、有償プランを契約する必要があります。監視ツールを利用していない場合や、自前でエラー通知だけ行っていると、有償ツールの利用に抵抗があるかもしれません。しっかりと使いこなせばコスト以上に十分なリターンがあると感じているため、本記事により、Sentryの利用体験が少しでも向上すれば幸いです。※特にSentryの回し者ではありません。 導入目的 エラーの発生をSlack経由で検知し、その時の状況を分かりやすい形で確認できること、そしてエラーへの対応ワー
SlackとSentryで整備するエラー監視体制
初めに こんにちは。今年4月からカナリーに新卒で入社した小野です。（記事テーマの実装中はインターン中でしたが、無事卒業・入社することができました🎉） 私たちは現在「Canary」というお部屋探しのアプリを作っています。 今回はそのCanaryのネイティブアプリのエラー監視に関するお話です！ 以前から、私たちはSentryを用いてエラー監視をしていたのですが、さまざまな問題を抱えていました。 問題点 大きな問題点が3つありました。 アラート通知が整備されていないので、わざわざSentry上に見に行く必要がある エラー自体は把握できるが、発見後の解消フローが未確立 無駄に通知されているエラーが多く、オオカミ少年アラートになっている 今まではサービスを軌道に乗せるために機能開発に全力を注いできましたが、Canaryのインストール数が250万を突破し、テレビCM放映も決まったことで今後もユーザー
.envとruntimeConfigを用いた環境変数の設定方法とappConfigとの使い分け【Nuxt3】
.env と runtimeConfig を用いた環境変数の利用方法【Nuxt3】 ※ 環境 Nuxt 3.2.3 Node v18.11.0 Nuxt3 で環境変数を利用するには、 useRuntimeConfigを使う .envファイルを作成し、その中で定義する の 2 パターンの方法があります。 また、同じような設定ファイルで、useAppConfigを使う方法もあります。 今回は、それぞれの使い方・使い分けについて解説していきます。 useRuntimeConfig を使う 以下のようにruntimeConfigをnuxt.config.tsで定義することでランタイムの構成を使うことができます。 nuxt.config.ts export default defineNuxtConfig({ runtimeConfig: { serverEnv: "serverValue", pu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Nuxt3+VitestでuseStateのテストを書く
