【jest】フロントエンドで自動テスト！
どうも、こんにちは。最近Reactでモノを作ることが多いNeji（ねじ）です。
初めて書いたよjest！
私が経験したフロントエンド開発では、ぶっちゃけテストを書くことがありませんでした。「動く＝オッケー！」という牧歌的な世界。
それでも、プロジェクトが発達してくると「使い回しできる部分をライブラリに切り出したい＝自動テストが必要！」となってきます。ビバ発展。
ということで、いよいよJavaScript用のテストケース、を書き始めることになりました。
とても助かる参考文献！
React公式：テストレシピ
jest公式：
偉大な先人の記事：
このあたりの資料が、大変参考になりました。
以下、実際に「Reactアプリのテストケースを書いてみた」ときのメモです。
セットアップ自体は↑の記事に従いnpmインストールすればOK。ぜんぜん難しくない。
jestは、基本が「commonJSベース」。「ES6ベース」ではない。
例えばES6ベースのimport構文が使えない。なのでReact用のJSをそのままjestにかけられない。
なので babel等を使い、ES6→commonJSにトランスパイルしjestを実行することになる。
jsx, TypeScriptも対応可能。
ここも、同じく「トランスパイラで凌ぐ」。
TypeScript対応は方法がいくつかあり「TypeScriptの型判定もしたいならtscを導入する」等。
自分は「とりあえずベタなトランスパイルオンリー」にした。
「jsライブラリのテスト」と「Reactコンポーネントのテスト」で結構テストのスタイル違うよ。
jsライブラリ：いわゆる単体テスト。
Reactコンポーネント：生成されたHTMLを正解と比較する「スナップショットテスト」が適している。
データ整備系が豊富。
グローバル変数、Reactコンポーネントのprops、コールしているAPIのダミー、他コンポーネント参照のMock化、など一通りやり方整っているよ。
といった感じ。
「テストしやすい設計」をしよう！
久しぶりにテストケースを書いてみると「テストしやすいクラス」にしておくのが大事だな、と思います。もう一歩踏み込んで「最初にテストケースを書こう（＝クラス／メソッドの振る舞いを先に決めておこう）」は、やはりアリだな、とも感じました。
まぁ現場では「工数の都合がつくか」という課題もありますが。