next page tester
1.0.0
Next.jsは、この図書館で採用されたテストアプローチを廃止する開発コースを受講しました。次のページテスターメンテナーは、代わりにブラウザテストを使用することを提案します。
next.jsのための欠落DOM統合テストツール
next.jsルートが与えられた場合、このライブラリは、next.jsのルーティングシステムとデータフェッチのメソッドから派生した予想される小道具を備えたJSDOMのマッチングページをレンダリングします。
import { getPage } from 'next-page-tester' ;
import { screen , fireEvent } from '@testing-library/react' ;
describe ( 'Blog page' , ( ) => {
it ( 'renders blog page' , async ( ) => {
const { render } = await getPage ( {
route : '/blog/1' ,
} ) ;
render ( ) ;
expect ( screen . getByText ( 'Blog' ) ) . toBeInTheDocument ( ) ;
fireEvent . click ( screen . getByText ( 'Link' ) ) ;
await screen . findByText ( 'Linked page' ) ;
} ) ;
} ) ; このライブラリの背後にあるアイデアは、次のようにできるだけ密接に繁殖することです。JSはサーバーを紡ぐことなく動作し、ローカルJSDOM環境で出力をレンダリングすることです。
貴重なテストエクスペリエンスを提供するために、 next-page-tester実際のnext.jsアプリケーションのレンダリングフローを複製します。
head要素を含む）マウントされたアプリケーションはインタラクティブであり、任意のDOMテストライブラリ（ @testing-library/reactなど）でテストできます。
next-page-testerが世話をします：
getServerSideProps 、 getInitialProps 、またはgetStaticProps ）_appおよび_documentコンポーネントを備えたラッピングページLink 、 router.push 、 router.replace経由のクライアントサイドナビゲーションをエミュレートするredirectリターンを処理しますnext/router 、 next/head 、 next/link 、 next/configおよび環境変数のサポート getPageオプションオブジェクトを受け入れ、4つの値を返します。
import { getPage } from 'next-page-tester' ;
const { render , serverRender , serverRenderToString , page } = await getPage ( {
options ,
} ) ;タイプ： () => { nextRoot: HTMLElement<NextRoot> }
返品： #__next nextルート要素。
高度なユースケースがない限り、この方法を主に使用する必要があります。ボンネットの下では、 serverRender()を呼び出してから、ReactアプリケーションをJSDOM #__nextルート要素にマウント/ハイドレートします。これは、ユーザーがページにアクセスしたときに取得/表示するものです。
タイプ： () => { nextRoot: HTMLElement<NextRoot> }
返品： #__next nextルート要素。
サーバーサイドの出力をDOMに挿入しますが、反応はマウントされません。それを使用して、次のシナリオで次のシナリオで次のレンダリングをテストするかをテストします。
タイプ： () => { html: string }
サーバーサイドレンダリングの出力をHTML文字列としてレンダリングします。これは、副作用のない純粋な方法です。
タイプ： React.ReactElement<AppElement>
アプリケーションの反応要素。
| 財産 | 説明 | タイプ | デフォルト |
|---|---|---|---|
| ルート（必須） | 次のルート（ /で開始する必要があります） | string | - |
| req | デフォルトのモックされた要求オブジェクトを強化します | req => req | - |
| res | デフォルトのモックされた応答オブジェクトを強化します | res => res | - |
| ルーター | デフォルトのモックされた次のルーターオブジェクトを強化します | router => router | - |
| useapp | カスタムアプリコンポーネントをレンダリングします | boolean | true |
| ドキュメントコンポーネントをレンダリングします | boolean | false | |
| Nextroot | next.jsルートフォルダーへの絶対パス | string | AUTOが検出されました |
| dotenvfile | .envファイル保持環境変数への相対パス | string | - |
| ラッパー | ラッパーファイルへの絶対パス。モックされたプロバイダーでコンポーネントツリーを飾るのに役立ちます。 | string | - |
| SharedModules | クライアントとサーバーのコンテキストの間でアイデンティティを保持する必要があるモジュールのリスト。 | string[] | [] |
ページ/コンポーネントインポートファイルタイプは、node.js （スタイルシート、画像、 .svgなどなど）によってネイティブに処理されない場合、テスト環境を適切に処理するように構成する必要があります。たとえば、Jestの場合、 moduleNameMapperを構成したい場合があります。
next-page-tester JSDOM環境にぶつかると予想しています。 Jestを使用してこの行をjest構成に追加する場合：
"testEnvironment" : "jsdom" ,next.jsはJSDOM環境で実行するように設計されていないため、デフォルトのJSDOMをセットアップして、よりスムーズなテストエクスペリエンスを可能にする必要があります。デフォルトでは、 next-page-tester次のとおりです。
window.scrollToとIntersectionObserverモックを提供しますただし、 NPT_SKIP_AUTO_SETUP env変数をtrueに設定して、自動クリーンアップとヘルパーの初期化をスキップすることを選択できます。あなたはそうするようなcross-envでこれを行うことができます：
cross - env NPT_SKIP_AUTO_SETUP = true jestJest V26を使用する場合は、適切なサーバー/クライアント環境でモジュールをロードするためにパッチを当てる必要がある場合があります。メンテナンスの取り組みは、最新のJestバージョンをターゲットにします。
例フォルダーの下でnext-page-testerが有効にするテストケースを文書化しています。
next-page-tester next.jsとJestの最後のバージョンのみをサポートすることに焦点を当てています。
| 次のページテスター | next.js | 冗談 |
|---|---|---|
| V0.1.0-> V0.7.0 | v9.xx | V26.xx |
| V0.8.0-> V0.22.0 | V10.0.0-> V10.0.7 | |
| v0.23.0-> v0.25.x | V10.0.8-> V11.0.x | |
| V0.26.0-> V0.27.x | V10.0.8-> V11.0.x | V27.xx |
| V0.28.0-> V0.28.x | V11.1.0 | |
| V0.29.0 + | v11.1.1-> v11.x | |
| V0.31.0 + | V12.1.0 | |
| V0.32.0 + | V12.1.1 + |
以来：
next.jsの将来のバージョンのサポートを箱から出して保証することはできないことに注意してください。パッチやマイナーバージョンでさえ壊れる可能性があります。この場合、新しいnext-page-testerバージョンがリリースされるのを待つ必要があります。
貢献は大歓迎です。外部の貢献者をサポートするために最善を尽くしています。
reqとresオブジェクトは、ノード-Mocks-httpでmockedされますstrictモードでTypeScriptを使用するときは@types/react-domおよび@types/webpackをインストールする必要があるかもしれませんuseDocumentオプションuseDocumentオプションは部分的に実装されており、不安定である可能性があります。
ネットワークリクエストをモックする最初の推奨方法は、 Mock service workerやMirage JSなどのライブラリを使用してネットワークレイヤーをock笑することで構成されています。
別の実行可能なアプローチは、Global fetchオブジェクトをfetch-mockのようなライブラリをock笑することで構成されている場合があります。
データの取得を担当するユーザーランドモジュールをock笑するより伝統的なアプローチが必要な場合は、追加のステップを検討する必要があります。「クライアント」と「サーバー」レンダリングの間のモジュール（ next-page-testerコンテキスト）で作成されたモック（クライアント）がサーバーコンテキストで実行されないため（例：データフェッチのメソッド）。
それを克服するには、そのようなモジュールを「クライアント」と「サーバー」コンテキストの間でsharedModulesオプションに渡すことにより、そのようなモジュール（保存/共有）する必要があります。
test ( 'as a user I want to mock a module in client & server environment' , async ( ) => {
const stub = jest . spyOn ( api , 'getData' ) . mockReturnValue ( Promise . resolve ( 'data' ) )
const { render } = await getPage ( {
route : '/page' ,
nextRoot ,
sharedModules : [ ` ${ process . cwd ( ) } /src/path/to/my/module` ] ,
} ) ;
expect ( stub ) . toHaveBeenCalledTimes ( 1 ) ; // this was executed in your data fetching method
} getPage呼び出す前に、Cookieをdocument.cookieに追加してCookieを設定できます。 next-page-testerはctx.req.headers.cookieにCookieを伝播し、データフェッチのメソッドで利用できるようになります。これは、クライアントサイドナビゲーションによってトリガーされる後続のフェッチングメソッドコールにも適用されます。
test ( 'authenticated page' , async ( ) => {
document . cookie = 'SessionId=super=secret' ;
document . cookie = 'SomeOtherCookie=SomeOtherValue' ;
const { render } = await getPage ( {
route : '/authenticated' ,
} ) ;
render ( ) ;
} ) ;注： document.cookieは自動的にクリーンアップされません。すべてを隔離しておくために、各テストの後に手動でクリアする必要があります。
next.js Linkコンポーネントは、JSDOM環境で実装されていないクリック時にwindow.scrollToを呼び出します。エラーを修正するには、テスト環境を設定するか、独自のwindow.scrollTo mockを提供する必要があります。
この警告は、ページがサーバーとブラウザの間で異なるレンダリングをレンダリングすることを意味します。これは、予想される動作であるか、コードのバグを知らせることができます。
この警告は、レンダリングプロセス中のアプリケーションが、模倣されていないネットワーク要求を実行することを意味します。必要に応じてそれらを見つけてock笑する必要があります。
trailingSlashオプションをサポートすることを検討してください_errorページdebugオプションを提供しますこれらの素晴らしい人々に感謝します（絵文字キー）：
アンドレア・カラロ ？ | matejšnuderl ？ | ジェイソン・ウィリアムズ ？ | arelaxend ？ | Kfazinic ？ | トマス・ロンディオ ？ | アレクサンダー・メンデス |
ヤンセプケ ？ | davidorchard ？ | ドア・イスマエル ？ | アンドリュー・ハール ？ | Massimeddu-sonic ？ | ジェス・テルフォード ？ | ジョセフ ？ |
Gergo Tolnai ？ | ブレット ？ | Vlad Elagin | ダニエル・ストックマン | Madeuz | デレクオースティン博士 ？ | フィアガル ？ |
Jan R. Biasi ？ | OtávioAugusto Soares ？ |
このプロジェクトは、全委員会の仕様に従います。あらゆる種類の貢献を歓迎します！
