今週は cli ツールにテストを追加することになっていました。これまでのところ、最もイライラすることです。

ジェストを選んだ理由

私は TDD (テスト駆動開発) の大支持者です。ほぼすべてのピースコードをテストする必要があります。協力期間中、私は PR のテストを書くことに時間の半分以上を費やしました。この経験がテストの必要性を本当に理解させてくれたと思います。 JS と Ruby のテスト フレームワークが非常に似ていることに驚きました。私は、協力プレイ中に使用した RSpec によく似た Jest を使用しました。 http リクエストを模擬するために、VCR と呼ばれるものに似た Nock を使用しました。

私が直面した問題（多くの問題）

私が直面した主な問題は、CommonJS の代わりに ESM を使用したことでした。そのせいで私の人生はさらに困難になりました。最初の問題は jest.mock が機能しないことでした。少し調べた結果、ESM ではモックの方法が異なることがわかりました。残念ながら、ドキュメントに従っても動作させることができませんでした。したがって、jest.spyOn を実行する必要がありました。私が直面した2番目の問題は、execaがchild_processでindex.test.jsを実行するため、実行してもカバレッジレポートには影響しないということでした。そのため、jest.spyOn を使用してテストを書き直す必要がありました。また、jest に渡すフラグを受け取らないように、index.js をリファクタリングする必要がありました。私が直面した他の小さな問題は、 jest -c jest.config.mjs の代わりに、node --experimental-vm-modules --no-warnings node_modules/jest/bin/jest.js -c jest.config.mjs を使用することでした。 ESMを使用して。また、単純な jest.spyOn では十分にテストできなかったため、mock-fs を使用してファイル システムを複製し、FilepathResolver.test.js をテストする必要がありました。 ESM を使用するだけで、これほど多くの障害が発生することに驚きました。ESM は、まさに JS がどれほど厄介なものかを反映しています。

何度も試行錯誤した結果、かなり良いカバレッジが得られました。