next page tester
1.0.0
Next.js a suivi un cours de développement qui rend l'approche de test adoptée par cette bibliothèque obsolète. Les responsables des testeurs de page suivants suggèrent d'utiliser plutôt des tests de navigateur.
L'outil de test d'intégration DOM manquant pour next.js.
Compte tenu d'un itinéraire suivant.js, cette bibliothèque rendra la page de correspondance dans JSDom , fournie avec les accessoires attendus dérivés du système de routage de Next.js et des méthodes de récupération de données .
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' ) ;
} ) ;
} ) ; L'idée derrière cette bibliothèque est de se reproduire aussi étroitement que possible comme le chemin Suivant.js fonctionne sans filtrer les serveurs et de rendre la sortie dans un environnement JSDom local.
Afin de fournir une expérience de test précieuse next-page-tester reproduit le flux de rendu d'une application réelle next.js :
head ) L'application montée est interactive et peut être testée avec n'importe quelle bibliothèque de tests DOM (comme @testing-library/react ).
next-page-tester s'occupera de:
getServerSideProps , getInitialProps ou getStaticProps ) si le cas_app et _documentLink , router.push , router.replaceredirect des pagesnext/router , next/head , next/link , next/config and Environment Variables getPage accepte un objet d'option et renvoie 4 valeurs:
import { getPage } from 'next-page-tester' ;
const { render , serverRender , serverRenderToString , page } = await getPage ( {
options ,
} ) ; Type: () => { nextRoot: HTMLElement<NextRoot> }
Renvoie: #__next Root Element Element.
À moins que vous n'ayez un cas d'utilisation avancé, vous devez principalement utiliser cette méthode. Sous le capot, il appelle serverRender() puis monte / hydrate l'application React dans l'élément racine JSDom #__next . C'est ce que les utilisateurs obtiendraient / verraient lorsqu'ils visitent une page.
Type: () => { nextRoot: HTMLElement<NextRoot> }
Renvoie: #__next Root Element Element.
Injectez la sortie du rendu côté serveur dans le DOM mais ne monte pas réagir. Utilisez-le pour tester comment Next.js rend dans les scénarios suivants:
Type: () => { html: string }
Rendez la sortie du rendu côté serveur en tant que chaîne HTML. Il s'agit d'une méthode pure sans effets secondaires.
Type: React.ReactElement<AppElement>
Élément de réaction de l'application.
| Propriété | Description | taper | Défaut |
|---|---|---|---|
| route (obligatoire) | Suivant d'itinéraire (doit commencer par / ) | string | - |
| req | Améliorer l'objet de demande moqué par défaut | req => req | - |
| res | Améliorer l'objet de réponse moqué par défaut | res => res | - |
| routeur | Améliorer l'objet de routeur prochain moqué par défaut | router => router | - |
| usabeapp | Rendre le composant d'application personnalisé | boolean | true |
| Rendre le composant de document | boolean | false | |
| nextroot | Path absolu vers le dossier racine Suivant.js | string | détecté automatique |
| file | Chemin relatif vers un fichier .env détenir des variables d'environnement | string | - |
| emballages | Chemin absolu vers le fichier des wrappers. Utile pour décorer l'arbre des composants avec des fournisseurs moqués. | string | - |
| Modules partagés | Liste des modules qui devraient préserver l'identité entre le contexte client et serveur. | string[] | [] |
Si vos pages / composants importent des types de fichiers non gérés par Node.js (comme des feuilles de style, des images, .svg , ...), vous devez configurer votre environnement de test pour les traiter correctement. Par exemple, en cas de plaisanterie, vous voudrez peut-être configurer un moduleNameMapper .
next-page-tester prévoit de rencontrer un environnement JSDom. Si l'utilisation de plaisanterie, ajoutez cette ligne à votre configuration jest :
"testEnvironment" : "jsdom" , Étant donné que Next.js n'est pas conçu pour s'exécuter dans un environnement JSDom, nous devons configurer le JSDom par défaut pour permettre une expérience de test plus fluide. Par défaut, next-page-tester :
window.scrollTo et des simulations IntersectionObserver Cependant, vous pouvez choisir de sauter l'initialisation Auto Cleanup & Helers en définissant la variable Env NPT_SKIP_AUTO_SETUP sur true . Vous pouvez le faire avec cross-env comme:
cross - env NPT_SKIP_AUTO_SETUP = true jestSi l'utilisation de Jest V26, vous devrez peut-être le corriger afin de charger des modules avec des environnements serveurs / clients appropriés. Les efforts de maintenance cibleront la dernière version de la plaisanterie.
Dans le dossier d'exemples, nous documentons les cas de test que next-page-tester active.
next-page-tester se concentre sur la prise en charge uniquement de la dernière version de Next.js et Jest:
| T-Tester | Next.js | Plaisanter |
|---|---|---|
| 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 + |
Depuis:
Veuillez noter que nous ne pouvons garantir la prise en charge des futures versions de Next.js hors de la boîte. Même les patchs ou les versions mineures pourraient se casser. Dans ce cas, vous devrez attendre la sortie d'une nouvelle version next-page-tester .
Les contributions sont les bienvenues et nous faisons de notre mieux pour soutenir les contributeurs externes.
req des méthodes de récupération des données et les objets res sont moqués de nœuds-mocks-http@types/react-dom et @types/webpack lors de l'utilisation de TypeScript en mode strict en raison de ce bogueuseDocument L'option useDocument est partiellement implémentée et peut être instable.
Le premier moyen suggéré de se moquer des demandes de réseau, consiste à se moquer de la couche de réseau avec des bibliothèques comme Mock service worker et Mirage JS .
Une autre approche viable pourrait consister à se moquer de l'objet Global fetch avec des bibliothèques comme fetch-mock .
Dans le cas où vous vouliez une approche plus traditionnelle impliquant une moquerie des modules de terrain utilisateur responsables de la récupération des données, vous devez envisager une étape supplémentaire: puisque les modules next-page-tester entre les modules "Client" et "Server" Rendu, les moqueries qui sont créées dans les tests (contexte client) ne s'exécuteront pas dans le contexte du serveur (par exemple les méthodes de récupération de données).
Pour surmonter cela, nous devons «souiller» ces modules pour (préserver / partager) leur identité entre le contexte «client» et «serveur» en les faisant passer par l'option 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
} Vous pouvez définir des cookies en les ajoutant sur document.cookie avant d'appeler getPage . next-page-tester propagera les cookies vers ctx.req.headers.cookie afin qu'ils soient disponibles pour les méthodes de récupération des données. Cela s'applique également aux appels de méthodes de récupération ultérieurs déclenchés par la navigation côté client.
test ( 'authenticated page' , async ( ) => {
document . cookie = 'SessionId=super=secret' ;
document . cookie = 'SomeOtherCookie=SomeOtherValue' ;
const { render } = await getPage ( {
route : '/authenticated' ,
} ) ;
render ( ) ;
} ) ; Remarque: document.cookie ne se nettoie pas automatiquement. Vous devrez l'effacer manuellement après chaque test pour garder tout isolé.
Next.js Le composant Link invoque window.scrollTo sur cliquez qui n'est pas implémenté dans l'environnement JSDom. Afin de corriger l'erreur, vous devez configurer votre environnement de test ou fournir votre propre window.scrollTo .
Cet avertissement signifie que votre page rend différemment le serveur et le navigateur. Cela peut être un comportement attendu ou signaler un bug dans votre code.
Cet avertissement signifie que votre application pendant le processus de rendu effectue certaines demandes de réseau qui ne se sont pas moquées. Vous devriez les trouver et se moquer au besoin.
trailingSlash ._errordebug pour enregistrer les informations d'exécution Merci à ces gens merveilleux (clé emoji):
Andrea Carraro ? | Matej šnuderl ? | Jason Williams ? | arelaxend ? | kfazinique ? | Tomasz Rondio ? | Alexander Mendes |
Jan Sepke ? | Davidorchard ? | Doaa Ismael ? | Andrew Hurle ? | massimeddu-sonic ? | Jess Telford ? | Joseph ? |
Gergo Tolnai ? | Brett ? | Vlad Elagin | Daniel Stockman | madeuz | Dr Derek Austin ? | Peur ? |
Jan R. Biasi ? | Otávio Augusto Soares ? |
Ce projet suit les spécifications de tous les contributeurs. Contributions de toute nature bienvenue!
