今日もどんより写経日和です（違）。
前回の記事に引き続き、写経していきます。
[jestによるテスト]
jestというテスティングフレームワークがデフォルトで付いてくるらしい。万歳。
恥ずかしながらようやくここ1年くらいでJUnitによるテストコードを本格的に書き始めたところなので、今年はJavaScriptのテストコードも書いていく所存。
早速npm testコマンドを実行する。
エラーだ。動じずに記事を読み進める。
jestの実行環境がネイティブアプリではなく通常のnode環境となるため、ネイティブアプリの呼び出し部分は失敗する、とのこと。
記事に書かれている通り、getDeviceLocale()をモックするコードを__tests__/App.jsの末尾に追記して、あらためてテストを実行する。
今度はグリーンのPASSの文字が。よかったよかった。
[jestテストの自動実行]
npm install -- --watchAllでテストの自動実行を試す。
先ほど追加したモックコードを除去して初期状態に戻し、保存する。と、テストがすぐさま実行され、FAILだのERRだの心臓に悪い感じの赤文字がたくさん表示された。
モックコードを復元して保存すると、やはり即時テストが実行される。今度はグリーンの文字が。目に優しい。
テスト自動実行便利だ。テストコード書くときとかに使えそう。
ともあれここで一旦テストの自動実行はオフにしておく。
[仮想DOMのスナップショットテスト]
意図せぬUI変更をテストするために、スナップショットテストというやり方があるらしい。ふむふむ。
スナップショットをテストするためのコードを写経して、テストを走らせる。
__snapshots__ディレクトリが追加された。
中身はこんな感じでスタイルとかが完全に適用された状態のReactコードっぽいものが。
再度テストの自動実行を有効にする。
記事の記載に従って、スナップショットテストを失敗させるように、テスト対象のApp.js本体をAtomで開き、UIに変更を加える。
すぐさまエラーがでる。
記事中ではここでnpm test -- -uコマンドでスナップショットを更新できる、とあるが、今は自動実行中なので、画面のススメに従ってwを入力して使用例を確認する。
どうやらuを入力するとスナップショットを更新できるらしいので、言われた通りにしてみる。
すぐにテストが実行されて、グリーンの表示に。安堵。
[スナップショットの取り扱い]
スナップショットファイルはコミットすべきか悩んだので、公式サイトを見てみる。
全てのスナップショットファイルはコミットすべし、と書かれている。そりゃそうだ、他の人が更新した差分のスナップショットとか毎回ローカルで作り直すのかって話ですよ。チームで開発することを考えれば当たり前か。
適当にApp.jsのスタイルシートを変更して、テストを走らせる。予想通り失敗。今度はnpm test -- -uを実行する。テスト成功。
公式サイトの勧めに従って、差分も含めてコミットしておくことにする。
そういや、仕事でReact使ってるプロジェクトあるけど、UI周りのテストどうなってるのか気にしたことなかった。無かったら来週書いてみよう。去年から特にテスト駆動開発を意識して仕事していることだし。
と思いつつ公式サイトをスクロールしていくと、スナップショットテストはテスト駆動開発には通常向かないよ的なコメントが。そりゃそうか、手動でスナップショットファイル作るのはしんどそうだし。
[まとめ]
これで第２章は終わり。
例によって写経したコードはGithubで公開しています。
次は実アプリ開発の第３章へ進みます。
[2018/01/12追記]
続きを書いた。
