Reactのユニットテスト2021
React でユニットテストをするときのベストプラクティスはいつも悩むのですが、とりあえず 2021 年 2 月時点では、こうかなーというのをまとめてみます。 まずテストランナーは jest で確定です。ここで悩む要素はまずありません。 では、React のテストをどうやるか？です。 公式の react-dom/test-utils を使う 公式の react-test-renderer を使う @testing-library/react を使う 選択肢としてはこの三種類が有名なところでしょう。 公式という響きはとても魅力的ですが、実は公式ドキュメントから「ボイラープレートを減らすため、エンドユーザが使うのと同じ形でコンポーネントを使ってテストが記述できるように設計されている、React Testing Library の利用をお勧めします。」という形で、@testing-library
ついに jest の軍門に降った - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? もう駄目だ。ついに React 以外のプロジェクトでも Jest 一択になってしまった。 もともと自分の選択するテストツールは、むかしは jasmine、いまは mocha + chai（ときどき power-assert） をベースに周辺ツールと連携させていて、React を使うようになってしばらくして Jest を入れるようになった。ここ5年くらいのフロントエンド界隈では標準の一種だと思う。 それがどうしてこんなに Jest びいきになったのか。 その1. 楽 とにかく楽だからだ。 Jest の売りはオール・イン・ワンとゼロ・コンフ
idやclassを使ってテストを書くのは、もはやアンチパターンである - Qiita
いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです！しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
