next page tester
1.0.0
A Next.JS fez um curso de desenvolvimento que torna obsoleta a abordagem de teste por essa biblioteca. Os mantenedores de testadores da próxima página sugerem usar o teste do navegador.
A ferramenta de teste de integração DOM ausente para Next.JS.
Dada uma rota Next.js, esta biblioteca renderizará a página de correspondência no JSDOM , fornecida com os adereços esperados derivados do sistema de roteamento do Next.JS e métodos de busca de dados .
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' ) ;
} ) ;
} ) ; A idéia por trás dessa biblioteca é reproduzir o mais próximo possível do caminho a seguir.
Para fornecer uma experiência de teste valiosa next-page-tester replica o fluxo de renderização de um aplicativo next.js real :
head ) O aplicativo montado é interativo e pode ser testado com qualquer biblioteca de teste DOM (como @testing-library/react ).
next-page-tester cuidará de:
getServerSideProps , getInitialProps ou getStaticProps ) se o caso_app e _documentLink , router.push , router.replaceredirect das páginas de manuseionext/router , next/head , next/link , next/config e Environment Variables getPage aceita um objeto de opção e retorna 4 valores:
import { getPage } from 'next-page-tester' ;
const { render , serverRender , serverRenderToString , page } = await getPage ( {
options ,
} ) ; Tipo: () => { nextRoot: HTMLElement<NextRoot> }
Retorna: #__next Root Element.
A menos que você tenha um caso de uso avançado, você deve usar esse método principalmente. Sob o capô, ele chama serverRender() e, em seguida, monta/hidrata o aplicativo REACT no JSDOM #__next Root Element. É isso que os usuários receberiam/veriam quando visitarem uma página.
Tipo: () => { nextRoot: HTMLElement<NextRoot> }
Retorna: #__next Root Element.
Injete a saída da renderização do lado do servidor no DOM, mas não monta o React. Use -o para testar como o Next.js renderiza nos seguintes cenários:
Tipo: () => { html: string }
Renderize a saída da renderização do lado do servidor como string html. Este é um método puro sem efeitos colaterais.
Tipo: React.ReactElement<AppElement>
Elemento reagir do aplicativo.
| Propriedade | Descrição | tipo | Padrão |
|---|---|---|---|
| Rota (obrigatória) | Próxima rota (deve começar com / ) | string | - |
| Req | Melhorar o objeto de solicitação ridicularizado padrão | req => req | - |
| res | Melhorar o objeto de resposta ridicularizado padrão | res => res | - |
| roteador | Melhorar o objeto de roteador zombado de inadimplência aumentado | router => router | - |
| USEAPP | Renderizar componente de aplicativo personalizado | boolean | true |
| Renderizar componente do documento | boolean | false | |
| nextroot | Caminho absoluto para a pasta raiz do próximo.js | string | detectado automático |
| DOTENVFILE | Caminho relativo para um arquivo .env mantendo variáveis de ambiente | string | - |
| invólucros | Caminho absoluto para o arquivo Wrappers. Útil para decorar a árvore de componentes com provedores ridicularizados. | string | - |
| Modos compartilhados | Lista de módulos que devem preservar a identidade entre o contexto do cliente e do servidor. | string[] | [] |
Se suas páginas/componentes importam tipos de arquivos não tratados nativamente pelo Node.js (como folhas de estilo, imagens, .svg , ...), você deverá configurar seu ambiente de teste para processá -las corretamente. Por exemplo, no caso de brincadeiras, você pode configurar algum moduleNameMapper .
next-page-tester espera encontrar um ambiente JSDOM. Se usar o jest Adicione esta linha à sua configuração jest :
"testEnvironment" : "jsdom" , Como o Next.js não foi projetado para ser executado em um ambiente JSDOM, precisamos configurar o JSDOM padrão para permitir uma experiência de teste mais suave. Por padrão, next-page-tester será:
window.scrollTo e IntersectionObserver No entanto, você pode optar por pular a inicialização do Auto Cleanup & Helders, definindo a variável NPT_SKIP_AUTO_SETUP ENV como true . Você pode fazer isso com cross-env assim:
cross - env NPT_SKIP_AUTO_SETUP = true jestSe estiver usando o jest v26, talvez seja necessário corrigi -lo para carregar módulos com ambientes adequados para servidor/cliente. Os esforços de manutenção terão como alvo a mais recente versão de idiota.
Em Exemplos, a pasta estamos documentando os casos de teste que next-page-tester permitem.
next-page-tester se concentra em apoiar apenas a última versão do Next.js e Jest:
| próxima página-tester | Next.js | Jove |
|---|---|---|
| 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 + |
Desde:
Observe que não podemos garantir suporte para versões futuras do Next.js pronta para uso. Até o patch ou versões menores podem quebrar. Nesse caso, você terá que esperar que uma nova versão next-page-tester seja lançada.
As contribuições são muito bem -vindas e fazemos o possível para apoiar colaboradores externos.
req contexto e res Métodos de busca de dados são ridicularizados com nó-mocks-http@types/react-dom e @types/webpack ao usar o TypeScript no modo strict devido a este buguseDocument A opção useDocument é parcialmente implementada e pode ser instável.
A primeira maneira sugerida de zombar de solicitações de rede, consiste em zombar na camada de rede com bibliotecas como Mock service worker e Mirage JS .
Outra abordagem viável pode consistir em zombar do objeto Global fetch com bibliotecas como fetch-mock .
Caso você deseje uma abordagem mais tradicional que envolve a zombaria dos módulos de terra do usuário responsável pela busca de dados, você precisa considerar uma etapa extra: desde os módulos de isolados next-page-tester entre a renderização de "cliente" e "servidor", aqueles mancais criados em testes (contexto do cliente) não serão executados no contexto do servidor (por exemplo, os métodos de busca de dados).
Para superar isso, precisamos "manchar" esses módulos para (preservar/compartilhar) sua identidade entre o contexto "cliente" e "servidor", passando -os pela opção 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
} Você pode definir cookies anexando -os a document.cookie antes de ligar para getPage . next-page-tester propagará cookies para ctx.req.headers.cookie para que estejam disponíveis para os métodos de busca de dados. Isso também se aplica aos métodos de busca subsequentes chamadas de chamadas acionadas pela navegação do lado do cliente.
test ( 'authenticated page' , async ( ) => {
document . cookie = 'SessionId=super=secret' ;
document . cookie = 'SomeOtherCookie=SomeOtherValue' ;
const { render } = await getPage ( {
route : '/authenticated' ,
} ) ;
render ( ) ;
} ) ; Nota: document.cookie não é limpa automaticamente. Você terá que esclarecê -lo manualmente após cada teste para manter tudo isoladamente.
O componente Link next.js chama window.scrollTo no clique, que não é implementado no ambiente JSDOM. Para corrigir o erro, você deve configurar seu ambiente de teste ou fornecer sua própria window.scrollTo Mock.
Esse aviso significa que sua página renderiza de maneira diferente entre o servidor e o navegador. Este pode ser um comportamento esperado ou sinalizar um bug no seu código.
Esse aviso significa que seu aplicativo durante o processo de renderização executa algumas solicitações de rede que não foram ridicularizadas. Você deve encontrá -los e zombar conforme necessário.
trailingSlash_errordebug para registrar informações de execução Obrigado a essas pessoas maravilhosas (key emoji):
Andrea Carraro ? | Matej Šnuderl ? | Jason Williams ? | Arelaxend ? | kfazinic ? | 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 ? | Feargal ? |
Jan R. Biasi ? | Otávio Augusto voa ? |
Este projeto segue a especificação de todos os contribuintes. Contribuições de qualquer tipo de boas -vindas!
