Quais estruturas de teste podem ser usadas para o Node? O artigo a seguir compartilhará com você algumas estruturas de teste do Node.js. Espero que seja útil para você! 
Curso de introdução rápida ao Node.js: entre para aprender
Nota do editor: O autor deste artigo é Tianzhu, engenheiro de Node.js do Ant Group. Ele primeiro apresentará as bibliotecas de classes comumente usadas. No final do artigo, ele discutirá se o teste de unidade é necessário. para discutirmos juntos.
mocha e jest são comumente usados. O teste oficial do novo nó ainda está sendo aprimorado e o futuro é promissor.
$ mocha teste/egg-view-ejs.test.js renderizar ✓ deve renderizar com moradores locais ✓ deve renderizar com cache ✓ deve renderizar com layout ✓ deve gerar erro renderString ✓ deve renderString com dados ✓ deve renderString erro 6 passes (398ms)
Embora existam tantos Runners, seus padrões de saída estão todos no formato TAP e os resultados são produzidos por meio de diferentes Repórteres.
Apenas escrever um único teste não é suficiente. Precisamos saber se todos os processos de ramificação do código são cobertos, por isso geralmente precisamos usar ferramentas de cobertura de código.
Costumava ser istanbuljs, mas mais tarde o autor reescreveu nyc. Eles têm principalmente duas responsabilidades: uma é traduzir o código para inserir o código de empilhamento e a outra é dar suporte a vários repórteres para gerar relatórios de cobertura.
Mais tarde, estatísticas de cobertura integradas do V8
, ou seja, não há mais necessidade de traduzir o código e a coleta de dados de cobertura tem suporte nativo.
Então este autor escreveu um c8 focado na geração de relatórios de cobertura.
Para verificar resultados variáveis, assert é essencial.
Historicamente: expect.js, should.js, chai e power-assert, jest também tem seu próprio expect integrado.
Mas agora o assert/strict oficial do Node.js é realmente muito bom.
Entre eles, power-assert é o que nós da EggJS temos usado. Também mencionei isso há muitos anos: "Provavelmente a melhor biblioteca JS Assert - The Emperor's New Clothes".
const assert = require('power-assert');
descreva('teste/showcase.test.js', () => {
const arr = [1, 2, 3];
it('power-assert', () => {
assert(arr[1] === 10);
});
});
//saída:
4) test/showcase.test.js afirmação de poder:
AssertionError: # test/showcase.test.js:6
afirmar(arr[1] === 10)
|
| 2 falso
[1,2,3]
[número] 10
=> 10
[número] arr[1]
=> 2PS: Se você quiser verificar o conteúdo do arquivo, também escrevi um arquivo assert, bem-vindo para experimentá-lo.
Por se tratar de um teste unitário, muitas vezes é necessário simular o ambiente ou as respostas posteriores.
sinonjs não é ruim e suporta simulações, stubs, etc. jest também tem sua própria biblioteca simulada integrada.
Se for um teste HTTP, o nock é muito poderoso e pode ajudá-lo a simular a resposta do servidor.
nock('http://www.example.com')
.post('/login', 'nomedeusuário=pgte&senha=123456')
.resposta(200, { id: '123ABC' })No entanto, a biblioteca oficial de solicitação undici do Node.js também possui recursos Mock integrados.
Existe também um termo chamado instantâneo, que significa despejar os dados durante a operação e usá-los diretamente como dados simulados para o próximo teste, o que pode melhorar até certo ponto a eficiência da escrita de testes.
Para testar cenários do HTTP Server, a biblioteca supertest é indispensável.
descreva('GET /usuários', function() {
it('responde com json', async function() {
solicitação de devolução (aplicativo)
.get('/usuários')
.set('Aceitar', 'aplicativo/json')
.expect('Tipo de conteúdo', /json/)
.esperar (200)
.then(resposta => {
assert(response.body.email, '[email protected]');
});
});
});Um dos principais cenários de uso do Node.js é a CLI da linha de comando, como Webpack e Babel, que também exigem testes de unidade.
Isto é o que recomendamos:
GitHub - node-modules/clet: teste E2E de linha de comando
GitHub - node-modules/coffee: teste a linha de comando no Node.js
importar {runner, KEYS} de 'clet';
it('deve funcionar com padrão', async () => { await runner() .cwd(tmpDir, { init: true }) .spawn('npm init') .stdin(/name:/, 'example') // aguarde stdout e responda .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // valida stdout .notStderr(/ npm ERR/) .file('package.json', { name: 'example', version: '1.0.0' }) // valida arquivo });
Para rastreamento leve de páginas, você pode usar HTTP diretamente para solicitar a biblioteca Unci.
Para simular a execução real do navegador, Selenium e phantomjs foram usados nos primeiros dias.
Então o Google lançou oficialmente o titereiro Devido ao acúmulo do Chromium e baseado no protocolo devtools, ele rapidamente se tornou popular e matou os dois primeiros. Produtos concorrentes semelhantes incluem dramaturgo e cipreste.
A propósito, vou baixar macacajs, uma ferramenta de teste multiterminal. Além de navegadores, ela também suporta testes de APPs móveis e de desktop. É de código aberto por engenheiros da equipe Yuque.
Quando escrevemos código aberto, muitas vezes precisamos de serviços automatizados de integração contínua para nos ajudar a testar.
Os jogadores neste campo incluem: Travis, Appveyor, GitHub Actions, etc.
Agora eu basicamente uso o GitHub Actions, e o nível de integração é muito legal.
Não há dúvida de que o teste unitário é muito importante. É uma habilidade necessária e uma qualidade profissional de um programador qualificado.
É claro que não somos fanáticos por cobertura 100%. Em muitos casos, precisamos buscar o ponto de equilíbrio do ROI.
Primeiro de tudo, deixe-me corrigir um ponto de vista comum dos recém-chegados: escrever testes unitários é uma perda de tempo?
Na verdade, escrever testes unitários economizará seu tempo. A razão para essa visão contra-intuitiva é que as condições de comparação geralmente não são objetivas. Precisamos considerar o custo da regressão após modificar o código duas vezes sob os mesmos requisitos de qualidade.
Para uma comparação justa, além de considerar o "tempo para escrever um único teste", o que é facilmente esquecido é o "tempo para realizar testes de regressão após cada modificação do código":
Ao escrever um único teste, crie vários mocks de ramificação no estágio inicial, e o tempo para o teste de regressão é apenas digitar no teclado;
Sem escrever um único teste, você precisa atualizar o código no aplicativo e, em seguida, simular manualmente diversas situações para testar, como abrir um navegador e clicar em vários lugares diferentes.
O quão demorados esses dois são fica claro à primeira vista.
Nada mais é do que investimento inicial + custo de manutenção + ênfase na qualidade do retorno. Cada empresa tem sua própria balança na hora de tomar decisões após pesá-las.
Claro, muitos dos cenários que mencionei são bibliotecas de estrutura (incluindo front - end e Node.js), aplicativos do lado do servidor, ferramentas de linha de comando, etc. Exibição da interface do usuário ou carregamento e descarregamento rápido são Para a página de atividade, o custo de manutenção de teste único correspondente é realmente muito alto. Neste momento, é razoável abandonar apropriadamente os testes únicos de alguns ramos não essenciais com base no ROI.
Mas devemos entender que este é o último recurso. Podemos reduzir o custo de manutenção dos testes unitários por vários meios, mas não podemos afirmar que os testes unitários são inúteis.
Há também um teste de regressão semiautomático no campo front-end, que se baseia em diferenças para automatizar a comparação e depois lembrar o proprietário de prestar atenção ao impacto das mudanças. É exatamente como as bibliotecas de ferramentas acima, que estão todas aqui para ajudar a reduzir o custo de gravação de testes únicos.
Esta também é uma visão errada. Os testes de unidade devem ser escritos pelos próprios programadores , porque é o seu próprio código e você deve ser responsável por isso. Qualquer equipe com um pouco de padronização precisa de testes de CI ao enviar o código, caso contrário não haverá colaboração de qualidade na revisão do código.
Os alunos de teste são responsáveis por trabalhos de nível mais amplo, como testes de integração, testes de regressão e testes ponta a ponta .
A divisão do trabalho é diferente, então, por favor, não culpe os outros.
O teste unitário é muito necessário. Escrever testes unitários é a qualidade profissional básica dos programadores. Escreva o máximo que puder. Em cenários individuais, você pode fazer escolhas com base no ROI.