maesblog

Jest 24 リリース 💅 リフレッシュし、洗練され、TypeScriptフレンドリーに(日本語翻訳)

2019年1月25日に Jest の最新メジャーバージョンとなる Jest 24 がリリースされました。これまでで最大のメジャーリリースと言われていた Jest 23 から約 8 ヵ月ぶりのメジャーリリースです。ついに TypeScript に対応しました。今回のリリースはやはりこれに尽きると個人的には思っています。Jest の公式ブログのリリースに関する投稿『Jest 24: 💅 Refreshing, Polished, TypeScript-friendly』を日本語に訳しました。細かい内容については、当記事でぜひチェックしてみてください。

Jest 24: Refreshing, Polished, TypeScript-friendly
Jest 24: 💅 Refreshing, Polished, TypeScript-friendly

January 25, 2019 Simen Bekkhus

Today we are happy to announce the next major release of Jest – version 24! It’s been 4 months since the last minor release, and 8 months since Jest 23, so this upgrade is a big one, with something for everyone! Highlights include built-in support for TypeScript by upgrading the Jest internals to Babel 7, fixing some long-standing issues with missing console output and performance issues when computing large diffs, and a brand new sparkling website.

本日、Jest の新しいメジャーリリース(バージョン 24)を発表できて、わたしたちは幸せです!直前のマイナーリリースからは 4 ヶ月、Jest 23 からは 8 ヶ月経ちました。したがってこのアップグレードはみなさんにとって大きなものとなります!Jest の内部を Babel 7 にアップグレードすることによる TypeScript のビルトインサポート、大きな差分を計算する際のコンソール出力の欠落やパフォーマンスに関する長年の問題の修正、真新しいキラキラしたウェブサイトなどが今回の主な変更点です。✨

For a full list of all changes see the changelog.

すべての変更点については changelog を見てください。

New Website – 新しいウェブサイト

@orta has provided a beautiful redesign of Jest’s website, which has been implemented by community members @montogeek and @brainkim.

@orta が Jest のウェブサイトを美しく再デザインし、コミュニティメンバーの @montogeek@brainkim が実装しました。

The aim of the redesign was to highlight more of what makes Jest awesome, and to decouple the idea that Jest is primarily a tool for testing React apps – you can use Jest with all sorts of projects and we want to make that obvious. You can read more about the ideas behind the redesign in this issue.

再デザインの目的は、何が Jest を素晴らしくしているのかをもっと強調するため、そして Jest は主に React アプリをテストするためのツールであるという考えを切り離すためでした。みなさんは、Jest をあらゆる種類のプロジェクトで使うことができます。わたしたちはそれを明白なものとしていきたいです。再デザインの背景にある考えについてこの issue で確認することができます。

TypeScript support – TypeScriptへの対応

We’ve upgraded to Babel 7 internally for Jest 24, which comes with support for TypeScript projects. That means Jest can support transpiling TypeScript out of the box, as long as you configure Babel to use it with @babel/preset-typescript. One caveat to the default TypeScript support, similar to Flow, is that Babel will only strip out the type annotations to make your code valid JavaScript. It will not typecheck your code.

わたしたちは、Jest 24 のために TypeScript プロジェクトをサポートする Babel 7 へのアップグレードを内部的に行いました。つまり、Babel に @babel/preset-typescript を使うように設定さえすれば、その他は何をせずとも Jest が TypeScript のトランスパイルをサポートしてくれるということを意味しています。デフォルトの TypeScript サポートにおいての注意点としては、Flow と同じように、Babel は TypeScript のコードを Valid な JavaScript にするために、ただ型注釈を削除するだけだということです。コードの型チェックは行われません。

While Jest has supported Babel 7 since version 22 released in December 2017, it required usage of a bridge module in order to fit in with Jest’s support of Babel 6. In Jest 24 we have migrated entirely over to Babel 7, with great help from community member @milesj. This means that setup is now easier and we can take advantage of other Babel 7 features, such as config loading and automatic modules transpilation. Make sure to remove the babel-core@^7.0.0-bridge.0 as it’s not needed now.

2017 年 12 月にリリースされたバージョン 22 以降、Jest は Babel 7 をサポートしていましたが、Jest の Babel 6 のサポートと適合させるにはブリッジモジュールを使用する必要がありました。Jest 24 では、コミュニティメンバー @milesj の大きな協力により、Babel 7 への完全な移行を行いました。これによりセットアップはより簡単になり、設定のローディングや自動 modules 変換などの、Babel 7 の他の機能も利用できるようになりました。babel-core@^7.0.0-bridge.0 はもう必要ないので、忘れずに削除を行ってください。

If you want to run typechecks while you test, you should use ts-jest. You will need to configure the transformer, as Jest by default applies Babel to .ts (and .tsx) files. Alternatively, you can run tsc or even use a Jest runner to simultaneously transpile your TypeScript whilst running your tests! See jest-runner-tsc for more information.

もしテストの最中にタイプチェックを走らせたいなら、ts-jest を使う必要があります。Jest はデフォルトでは Bebel を .ts ファイルトや .tsx ファイルに適用させるので、トランスフォーマを設定する必要があるでしょう。一方で、tsc を走らせることも、テストを走らせている間に TypeScript を同時にトランスパイルするために Jest ランナーを使うこともできます。詳細は jest-runner-tsc を見てください。

Note that if you for whatever reason cannot upgrade to Babel 7, you can still use Jest 24 with babel@6 as long as you keep babel-jest at version 23.

もし、何らかの理由で Babel 7 にアップグレードできない場合でも、babel-jest をバージョン 23 で維持させておけば、Babel@6 でJest 24 を使用することができるということに注意してください。

test.todo

Jest 23 had a change that made tests missing an implementation throw instead of being skipped. This change was made due to feedback that accidentally skipped tests were hard to discover and hard to track down. However, this change broke the workflow for quite a few developers who used the feature to sketch out which tests to write.

Jest 23 ではテストをスキップさせる代わりに、throw の実装があれば失敗させるという変更がありました。この変更は、誤ってスキップされたテストは、発見することが困難であり、追跡することが困難であったということをフィードバックするために行われました。しかしながら、この変更は、どのテストを書くかスケッチするためにこの機能を使用した多くの開発者のワークフローを壊すことになりました。

In Jest 24, we are addressing this issue by adding an explicit test.todo (inspired by the excellent AVA), which will be printed separately in the test summary. It allows you to quickly sketch out which tests you want to write and in the future, an ESLint rule might even be able to warn you that you have forgotten to write out some tests.

Jest 24 では、テストサマリーの中で別々に出力される明示的な test.todo(素晴らしい AVA にインスパイアされました)を追加することで、この問題を修正しています。これにより、どのテストを書きたいかを瞬時にスケッチすることができるようになりました。そして将来的には ESLint のルールで、いくつかのテストを書き忘れたことを警告することさえもできるようになるかもしれません。

test.todo('invalid input should throw');

test.todo('missing options should be normalized');
test.todo

Improved Assertion Messages – アサーションメッセージの改善

When tests fail, you need to make confident and correct decisions which changes are expected progress and which changes are unexpected regressions. It is especially important not to miss a few regressions hidden among much progress. Jest 24 makes reports when assertions fail more clear and concise for several matchers. Because the effort will continue in Jest 25, you might notice some temporary inconsistencies. If your tests never fail, then you won’t get to see them – for the rest of us, it’ll be easier to debug why something isn’t working as expected. Thanks for the hard work by @ittordepam and other contributors from the community.

テストが失敗したときは、どの変更が期待通りの進捗で、どの変更が予期しない後退(リグレッション)であるかについて、自信を持って正しい判断を下す必要があります。たくさんの進捗の中に隠れいている数少ない後退を見逃さないことが特に重要です。Jest 24 はアサーションが失敗した時のレポートを、さまざまなマッチャーのためによりわかりやすく簡潔にしています。この根気の必要な作業は Jest 25 でも継続して行っていく予定なので、いくつかはまだ未対応であることに気付くかもしれません。もしテストが全然失敗しない人であれば、これらを見ることはないでしょう。残りの人たちは、なぜ期待通りに動かないのかデバッグすることが簡単になっていることに気付くでしょう。@ittordepam とコミュニティの他のコントリビューターたちによる貢献に感謝します。

You can see these changes across all these PRs: 7621, 7557, 7448, 7325, 7241, 7152, 7125, 7107, 6961.

これらの変更を次のプルリクエストをすべて見ることで確認できます: 7621, 7557, 7448, 7325, 7241, 7152, 7125, 7107, 6961

メッセージ例:

アサーションが失敗した場合

failing assertion

型がミスマッチの場合

different types

モック関数が呼び出されていない場合

mock functions

Fixing old pain

We’ve fixed a couple of really old issues in this release.

わたしたちは今回のリリースで 2 つの本当に古い問題を修正しました。

The first one we’d like to highlight is console.log statements going missing. Jest intercepts and collects all logs in order to give you a stack trace to them, as well as provide them to reporters so you can handle them however you want. However, this has led to an issue where they have simply been missing in certain edge cases. Luckily for Jest 24, @spion has stepped up and fixed this issue. Thank you very much!

最初に強調したい問題は、行方不明になっている console.log です。Jest はすべてのログをインターセプトして収集し、それらに対するスタックトレースを提供しています。同様にそれらを好きなようにハンドリングできるようにレポーターに提供しています。しかしながら、これは特定のエッジケースにおいて簡単に行方不明になってしまうという問題をもたらしました。幸いなことに、Jest 24 は @spion によって強化され、この問題は修正されました。ありがとうございます!

The second one is an issue where Jest runs out of memory if the difference in serialization of expected and received value has a huge number of insertion changes (either unexpected because of mistake in test or defect in serializer or expected because of temporary failures during test-driven development). @ittordepam has replaced the previous diffing algorithm with diff-sequences package, which should fix this issue because it uses the theoretical minimum amount of memory. It opens up possibility for word-diffs in the future, similar to what git provides. Please see this PR and don’t hesitate to reach out if you want to help make that happen!

2 つ目は、もし期待する値と受け取る値のシリアライズ化における違いに大量の挿入変更(テストのミスやシリアライザにおける欠陥による予期せぬものや、テスト駆動開発中の一時的な失敗による予期せぬもの)があった場合、Jest がメモリ不足になるという問題です。@ittordepam がこれまでの差分検出アルゴリズムを diff-sequences パッケージに置き換えました。このパッケージは理論上最小メモリ量を使用するので、この問題を解決してくれるはずです。gitが提供するのと同様に、将来的に word-diff の可能性を広げます。このプルリクエストを見て、これを実現する手助けをしてくださる場合は、躊躇せずご連ください!

Other highlights – 他の注目点

We have some improvements for globalSetup and globalTeardown as well – code transformation will be applied to them similar to setupFiles and they are now supported as part of projects.

globalSetupglobalTeardown に対してもいくつか改善を行いました。これらには、 setupFiles と同様にコード変換が適用されるようになります。また、これらはプロジェクトの一部としてサポートされるようになりました。

  • You can configure Jest’s snapshot location, this is mainly useful if you are building tools which use Jest in a larger build process.

    Jest のスナップショットの場所を設定することができるようになりました。これは、Jest をより大きなビルドプロセスで使用するツールをビルドしている場合に主に役立ちます。

  • A quirk of Jest’s CLI has been that while some flags and options have been camel cased (such as runInBand), others have not been (such as no-cache). In Jest 24, both are recognized, meaning you can write your CLI arguments however you want.

    Jest CLI にある変なところは、いくつかのフラグとオプションは(runInBand のように)キャメルケースとなっていますが、他は(no-cache のように)なっていないことです。Jest 24 では、両方とも認識されており、好きなように CLI 引数を記述できるようになりました。

  • We’ve renamed setupTestFrameworkScriptFile to setupFilesAfterEnv, and made it into an array. We hope this will make it more obvious what the options is for. We have plans to further overhaul the configuration in the next major, see the paragraph in the section below.

    setupTestFrameworkScriptFilesetupFilesAfterEnv に名前を変更し、配列にしました。これによりオプションが何のためにあるのかより明白になることを願っています。次のメジャーリリースで設定をさらに徹底的に見直す予定です。詳細は、この後のセクションを参照してください。

  • To reduce the amount of magic Jest performs to “just work”, in this release we decided to drop automatic injection of regenerator-runtime, which is sometimes used in compiled async code. Including regenerator-runtime is not always necessary and we believe it’s the user’s responsibility to include it if it’s needed. If you use @babel/preset-env with targets set to a modern Node version (e.g. Node 6+) you will not need to include it. Please see our Using Babel docs for more information.

    Jest が “just work™” するために行う魔術の量を減らすために、コンパイルされた非同期のコードで時々使われている regenerator-runtime の自動注入をこのリリースでやめる決断をしました。regenerator-runtime を含めることは常に必要ではなく、必要となった場合にユーザーの責務で含めるものだと思っています。もし targets を最新の Node バージョン(Node 6 以降など)に設定して @babel/preset-env を使用していたら、含める必要はありません。詳細については Using Babel のドキュメントをご覧ください。

  • Node.js 10 came with an experimental module called worker_threads, which is similar to Worker threads in the browser. jest-worker, part of the Jest platform, will be able to use worker_threads if available instead of child_process, which makes it even faster! Benchmarks show a 50% improvement. Due to its experimental nature, it’s not enabled when using Jest as a test runner, but you can use it in your own projects today! We plan to enable it by default when it’s promoted from experimantal status in Node.js.

    Node.js 10 には、ブラウザーにおける Worker threads に似た worker_threads と呼ばれる実験的なモジュールが付属していました。もし child_process の代わりに利用可能であれば、Jest platform の一部である jest-workerworker_threads を使えるようになり、さらに高速になるでしょう!ベンチマークでは 50% の改善を示しました。これは実験的な性質のため、テストランナーとして Jest を使う時は無効となりますが、ご自身のプロジェクトでは本日から使用することができます!Node.js の experimantal のステータスから昇格した時に、デフォルトで有効にする予定です。

Breaking Changes – 破壊的変更

While all breaking changes are listed in the changelog, there’s a few of them that are worth highlighting:

すべての破壊的変更は changelog にリストされていますが、ここで強調しておくべきものがいくつかあります。

  • We’ve upgraded to Micromatch 3. While this might not affect every user, it is stricter in its parsing of globs than version 2, which is used in Jest 23. Please read through this and linked issues for examples of invalid globs in case you have problems.

    Micromatch 3 にアップデートしました。これはすべてのユーザーには影響を与えないかもしれませんが、Jest 23 で使用されているバージョン 2 よりも glob の解析が厳密です。あなたが抱えている問題のケースにおける invalid な glob の事例に関して、こちらとリンクされた issue に目を通してください。

  • We’ve removed code remnants that was needed for Node 4. It was previously technically possible to run Jest 23 on Node 4 – that is no longer possible without polyfilling and transpiling.

    Node 4 のために必要だったコードを削除しました。以前は技術的に Node 4 で Jest 23 を動かすことは可能でしたが、ポリフィルとトランスパイルなしではもはや可能ではなくなりました。

  • Some changes to serialization of mock functions in snapshots – make sure to double check your updated snapshots after upgrading. Related PR.

    スナップショットにおけるモック関数のシリアライズに対するいくつかの変更があります。アップグレード後は更新されたスナップショットをダブルチェックして確認するようにしてください。関連のプルリクエストです。

  • Jest no longer automatically injects regenerator-runtime – if you get errors concering it, make sure to configure Babel to properly transpile async functions, using e.g. @babel/preset-env. Related PR.

    Jest はもはや自動的に regenerator-runtime を注入しなくなりました。もしこれに関するエラーが発生した場合、たとえば @babel/preset-env などを使用して、async functions を適切にトランスパイルするように Babel を設定するようにしてください。関連のプルリクエストです。

The future – 将来に向けて

We are incredibly humbled by the results in State Of JS 2018, where Jest won the “Highest Satisfaction” award. Another huge thing to happen in 2018 was in October, when Jest passed 2 million weekly downloads for the first time. Thank you.

わたしたちは、“Highest Satisfaction(最高の満足)” 賞を受賞した State Of JS 2018 の結果によって信じられないくらい謙虚になりました。2018 年に起きたもう一つの大きな出来事は、10月に初めて週のダウンロード数が 200 万を超えたということです。ありがとうございます。

We are very thankful for the trust in us shown by the community, and hope to build on it in the future. We will ensure Jest 24 and future releases will continue to build upon this incredible foundation, and continue to be an integral part of JavaScript developers’ toolkits.

わたしたちはコミュニティによって示されるわたしたちへの信頼について大変感謝しており、将来的にはさらに信頼を積み上げていきたいと思っています。わたしたちは、Jest 24 以降のリリースもこの信じられないほどの基盤の上に構築され続けていき、JavaScript 開発者にとって不可欠なツールキットの一部であり続けるものだと確信しています。

This has been the first release where we have explored the idea of using our Open Collective funding to create bug bounties. This worked well in getting non-core developers involved in the implementation of the new landing page, and we’re optimistic for a long running bug where Jest globals are mismatched from Node globals. We’d like to do more, if you have a pet bug that’s a good candidate for our bounty program, please let us know. In the meantime, you can find all the tickets with a bounty via the issue label.

Jest 24 は、わたしたちがバグ報奨金を作るために築いた Open Collective を使うことのアイデアを探してきた最初のリリースです。これはコア開発者ではない方たちを新しいランディングページの実装に巻き込むのに大変役に立ちました。また、わたしたちは Jest のグローバルと Node のグローバルが一致していないという長期に渡るバグに関しては楽観的に考えています。もしあなたが報奨金プログラムの対象となりうる身近なバグをお持ちであれば、わたしたちはもっと頑張りたいと思っていますので、おしらせください。それまでの間は、issue ラベルを通して報奨金の対象となるすべてのチケットを見ることもできます

We have already started to make plans for the next release of Jest 25, with the biggest planned feature being an overhaul of our configuration, which is pretty hard to grok, mainly because of overlapping option and mixing globs and regular expressions. Feedback on how you want Jest’s configuration to look is very much welcome, and can be submitted in this issue.

わたしたちはすでに次の Jest 25 のリリースの計画を作り始めています。計画しているもっとも大きな機能は、主に重複しているオプションやグロブと正規表現の組み合わせによって完全に理解するのが難しくなっている設定周りの徹底的な見直しです。どのように Jest の設定 があるべきかについてのフィードバックは大いに歓迎しています。こちらの issue から送信可能です。

You might also have heard that we are planning to migrate the code base from Flow to TypeScript. We are hopeful that this migration will enable even more contributors to jump in and help make 2019 even better for JavaScript testing. The plan is to land this in a minor release in the not too distant future. Feedback on this choice can be added to the RFC.

さらに、わたしたちがコードベースを Flow から TypeScript へ移行する計画を立てているということを聞いているかもしれません。わたしたちは、この移行によりさらに多くのコントリビュータが参加できるようになり、2019 年における JavaScript のテストをより良いものとなるよう手助けできることを願っています🚀。この計画は、そう遠くない時期にマイナーリリースで実施します。この選択に関するフィードバックは、こちらの RFC に追加可能です。

Lastly, if you’ve ever wondered about how Jest is built, @cpojer has recorded a video with an architectural overview of how Jest is put together under the hood. Feel free to reach out if you have any further questions about it. The video is available on our website.

最後に、もし Jest がどのように構築されているのかについて疑問がまだある場合は、@cpojer によって Jest がどのように組み立てられているかについてアーキテクチャ概要をビデオにしてくれています。もしさらなる疑問がある場合は、気軽に見てみてください。このビデオは当ウェブサイトでも見ることができます。

Happy Jesting!

Jest を楽しんでください!🃏

訳者まとめ

翻訳は以上です。やはり冒頭でも述べたように、TypeScript の対応が大きいかなと思っています。わたし自身も Angular に Storybook を導入して、スナップショットテストに対応させようとした時に、Jest の設定にてこずりました。今回の TypeScript 対応で Babel の設定が簡単になったのが良いですね。@babel/preset-typescript を設定するだけでよくなりました。

それから記事の最後の方に、State Of JS 2018 で “Highest Satisfaction(最高の満足)” 賞を受賞しと書いてありましたが、確かにわたしの周りでもよく Jest の話をする機会が多くなりました。Jasmine のマッチャーがそのまま使えるというのも Jest が普及した理由のひとつだと思っています。もちろんスナップショットテストが最強ですが。

ウェブサイトもデザインが一新され見やすくなりました。Jest のやる気がひしひしと伝わってきますね。2019 年は Jest からも目が離せなくなりますね。

関連記事

コメント

  • 必須

コメント