DEV Community: Vinicius Rodrigues

Maximize a Performance dos Seus Testes com Jest e Vitest

Vinicius Rodrigues — Wed, 02 Oct 2024 00:03:09 +0000

Introdução

Se você já criou testes automatizados para seu projeto, com certeza conhece o jest. Não é por acaso: O jest é uma das ferramentas de teste mais utilizadas no mercado e amplamente difundida pela comunidade de desenvolvimento.

Mas, independentemente da tecnologia, um código mal otimizado vai rodar mal. E se você estiver em um projeto grande, o simples ato de executar testes pode demorar o tempo de tomar um café (ou vários).

Eu não tenho nada contra sua pausa pro cafezinho, estou tomando um enquanto escrevo este artigo, mas ultimamente eu entrei de cabeça em uma missão: otimizar testes para que sejam o mais rápidos possível.

Bora pro código!

O cenário caótico

Para te mostrar isso eu vou propor um cenário caótico, uma API escrita em typescript e usando Fastify como web server. Os testes contém um problema de otimização e o Jest não tem nenhuma configuração além do básico para executar os testes.

//slow jest config

import { type Config } from '@jest/types';

const config: Config.InitialOptions = {
    preset: 'ts-jest',
    transform: {
        '^.+\\.tsx?$': 'ts-jest'
    },
    testMatch: [
        '**/slow.*'
    ]
};

export default config;

Você pode notar que o Jest usa uma outra biblioteca chamada ts-jest para conseguir ler nossos testes utilizando typescript. Esse já é nosso primeiro ponto de melhoria. Além disso podemos definir melhor nosso target, ou seja, onde o Jest vai buscar nossos testes.

Quanto aos testes, criei um arquivo com 300 testes iguais:

it('should pass', async () => {
    const app = await buildServer()

    const response = await app.inject({
      method: 'GET',
      url: '/check',
    })

    expect(response.statusCode).toEqual(200)
    expect(response.json()).toEqual({ hello: 'world' });
 });

Nosso erro premeditado aqui é que cada teste recria a instância do Fastify para cada execução, portanto, 300 vezes. Você pode pensar que isso é muito específico mas na verdade é uma forma de mostrar problemas que acontecem de várias formas e causam lentidão, por exemplo:

Instancias sendo recriadas (como no exemplo)
Alterações no banco de dados
Mocks
Validações desnecessárias

Otimizando o Jest

Vamos adicionar algumas configurações.

maxWorkers: Define quantos núcleos da CPU serão usados para os testes em paralelo, aqui configurado para usar 50%.
testEnvironment: Define o ambiente de execução, que neste caso é o "node".
testPathIgnorePatterns: Ignora diretórios como node_modules e src.

Nossa grande estrela aqui é o @swc/jest. Diferente do ts-jest, que transpila TypeScript usando o compilador do próprio TypeScript, o @swc/jest utiliza o SWC, um compilador escrito em Rust que é muito mais rápido para transformar arquivos TypeScript em JavaScript. O Rust, sendo uma linguagem de baixo nível, oferece desempenho superior, especialmente em grandes bases de código.

Além disso, configuramos também um caminho bem específico para o jest encontrar nosso teste em testMatch. Sei que não é um caso real mas você também poderia mudar para algo como **/*.test.ts e isso faria com que arquivos com outras extensões fossem ignorados.

// Fast jest config

import {
    type Config
} from '@jest/types';

const config: Config.InitialOptions = {
    cache: true,
    maxWorkers: '50%',
    testEnvironment: "node",
    testPathIgnorePatterns: [
        'node_modules',
        'src'
    ],
    transform: {
        '^.+\\.tsx?$': '@swc/jest'
    },
    testMatch: [
        '**/slow.test.ts'
    ]
};

export default config;

Feito isso, vamos fazer a comparação de ambas as configurações de Jest executando nossos testes que ainda tem o problema de otimização.

Tentativa	Slow Jest	Fast Jest
1	3.728s	2.939s
2	3.701s	2.982s
3	3.687s	2.904s
4	3.763s	2.934s
5	3.730s	2.911s

Médias:

Slow Jest: 3.722s
Fast Jest: 2.934s

Tivemos uma melhora de 21,17% com nosso Jest otimizado. Agora vamos corrigir o problema no nosso teste.

Otimizando o teste

Como disse antes, nosso caso não é tão complexo. O que vamos fazer aqui é mover a criação da instancia para nosso beforeAll e reutilizar em todos os testes.
O importante aqui é frisar que diferentes projetos podem gerar situações parecidas com essa e depende de você ter o senso crítico para entender e corrigir essas falhas.

describe('fast', () => {
    let app: FastifyInstance;
    beforeAll(async () => {
        app = await buildServer()
    })

    it('should pass', async () => {
        const response = await app.inject({
            method: 'GET',
            url: '/check',
        })

        expect(response.statusCode).toEqual(200)
        expect(response.json()).toEqual({ hello: 'world' });
    })
})

Com o problema corrigido vamos a uma nova execução.

Tentativa	Slow Jest	Fast Jest
1	3.318s	2.593s
2	3.316s	2.552s
3	3.302s	2.538s
4	3.328s	2.567s
5	3.278s	2.566s

Médias:

Slow Jest: 3.3044s
Fast Jest: 2.5632s

Agora temos uma nova melhoria nos tempos. Comparando a média do nosso pior cenário (3.722s) com o melhor cenário atual (2.5632s) temos uma melhoria de 31.1%.

Podemos melhorar?

Se você não tem a opção de mudar o Jest por outra ferramenta acredito que essa melhoria seja algo ótimo para você. Mas podemos ir além utilizando o Vitest.

Expandindo os horizontes com Vitest

Se você nunca ouviu falar do Vitest vou resumir, é uma biblioteca de testes compatível com o Jest e que usa o EsBuild por baixo dos panos. Sendo assim, você quase não precisa refatorar os testes escritos pro jest e o arquivo de configuração é muito simples e no nosso caso é opcional. Mas vou deixar as configurações que adicionei no nosso projeto:

import { defineConfig } from 'vitest/config'

export default defineConfig({
    test: {
        globals: true,
        environment: 'node',
        include: ['tests/fast.test.ts']
    }
})

Indo direto ao ponto, vou executar apenas o teste que foi corrigido e vamos comparar os resultados.

Tentativa	Slow Jest	Fast Jest	Vitest
1	3.287s	2.575s	1.690s
2	3.295s	2.564s	1.770s
3	3.279s	2.589s	1.711s
4	3.311s	2.555s	1.708s
5	3.291s	2.567s	1.757s

Médias:

Slow Jest: 3.293s
Fast Jest: 2.570s
Vitest: 1.727s

Comparando com o melhor tempo do Jest, o Vitest é 32% mais rápido. Quando olhamos para o nosso primeiro caso de testes o ganho é de 50%

Espero que tenha gostado! Fique a vontade para deixar sugestões e compartilhar com seus amigos e colegas de trabalho.

Speed Up Your Tests with Jest and Vitest

Vinicius Rodrigues — Wed, 02 Oct 2024 00:02:58 +0000

Introduction

If you've ever created automated tests for your project, you’re probably familiar with Jest. It’s no coincidence: Jest is one of the most widely used testing tools in the industry and is highly regarded within the developer community.

However, regardless of the technology, poorly optimized code will perform poorly. And if you’re working on a large project, the simple act of running tests can take as long as making a cup of coffee (or several).

I have nothing against your coffee break; I'm enjoying one while writing this article, but lately, I've dived headfirst into a mission: optimizing tests to make them as fast as possible.

Let’s get to the code!

The Chaotic Scenario

To illustrate this, I'll present a chaotic scenario: an API written in TypeScript using Fastify as the web server. The tests have an optimization problem, and Jest has no configuration beyond the basics to run the tests.

//slow jest config

import { type Config } from '@jest/types';

const config: Config.InitialOptions = {
    preset: 'ts-jest',
    transform: {
        '^.+\\.tsx?$': 'ts-jest'
    },
    testMatch: [
        '**/slow.*'
    ]
};

export default config;

You might notice that Jest uses another library called ts-jest to read our tests using TypeScript. This is already our first point of improvement. Additionally, we can better define our target, which is where Jest will look for our tests.

As for the tests, I created a file with 300 identical tests.

it('should pass', async () => {
    const app = await buildServer()

    const response = await app.inject({
      method: 'GET',
      url: '/check',
    })

    expect(response.statusCode).toEqual(200)
    expect(response.json()).toEqual({ hello: 'world' });
 });

Our deliberate mistake here is that each test recreates the Fastify instance for every execution, resulting in 300 instances. You might think this is a very specific case, but it actually serves to illustrate problems that can arise in various forms and cause slowdowns, such as:

Instances being recreated (like in this example)
Database modifications
Mocks
Unnecessary validations

Otimizando o Jest

Vamos adicionar algumas configurações.

Optimizing Jest

Let’s add some configurations.

maxWorkers: Defines how many CPU cores will be used to run tests in parallel; here, it’s set to use 50%.
testEnvironment: Sets the execution environment, which in this case is "node."
testPathIgnorePatterns: Ignores directories like node_modules and src.

Our star here is @swc/jest. Unlike ts-jest, which transpiles TypeScript using the TypeScript compiler, @swc/jest utilizes SWC, a compiler written in Rust that is significantly faster at transforming TypeScript files into JavaScript. Rust, being a low-level language, offers superior performance, especially in large codebases.

Additionally, we also configure a very specific path for Jest to find our test in testMatch. I know this isn’t a real case, but you could also change it to something like //.test.ts* to have it ignore files with other extensions.

// Fast jest config

import {
    type Config
} from '@jest/types';

const config: Config.InitialOptions = {
    cache: true,
    maxWorkers: '50%',
    testEnvironment: "node",
    testPathIgnorePatterns: [
        'node_modules',
        'src'
    ],
    transform: {
        '^.+\\.tsx?$': '@swc/jest'
    },
    testMatch: [
        '**/slow.test.ts'
    ]
};

export default config;

After making these changes, let's compare both Jest configurations by running our tests, which still have the optimization problem.

Attempt	Slow Jest	Fast Jest
1	3.728s	2.939s
2	3.701s	2.982s
3	3.687s	2.904s
4	3.763s	2.934s
5	3.730s	2.911s

Averages:

Slow Jest: 3.722s
Fast Jest: 2.934s

We achieved an improvement of 21.17% with our optimized Jest. Now let's fix the problem in our test.

Optimizing the Test

As mentioned earlier, our case isn’t too complex. What we’ll do here is move the instance creation to beforeAll and reuse it across all tests.
The important point here is to emphasize that different projects can create similar situations, and it's up to you to have the critical sense to identify and correct these flaws.

describe('fast', () => {
    let app: FastifyInstance;
    beforeAll(async () => {
        app = await buildServer()
    })

    it('should pass', async () => {
        const response = await app.inject({
            method: 'GET',
            url: '/check',
        })

        expect(response.statusCode).toEqual(200)
        expect(response.json()).toEqual({ hello: 'world' });
    })
})

With the problem fixed, let's run the tests again.

Attempt	Slow Jest	Fast Jest
1	3.318s	2.593s
2	3.316s	2.552s
3	3.302s	2.538s
4	3.328s	2.567s
5	3.278s	2.566s

Averages:

Slow Jest: 3.3044s
Fast Jest: 2.5632s

Now we see an improvement in the timings. Comparing the average of our worst case (3.722s) with the best current case (2.5632s), we have an improvement of 31.1%.

Can we improve further?

If you can’t switch Jest for another tool, I believe this improvement is excellent for you. But we can go further by using Vitest.

Expanding Horizons with Vitest

If you’ve never heard of Vitest, let me summarize: it’s a testing library compatible with Jest that uses EsBuild under the hood. Thus, you hardly need to refactor tests written for Jest, and the configuration file is very simple and optional in our case. But here are the configurations I added to our project:

In short, I’ll run only the corrected test and compare the results.

Attempt	Slow Jest	Fast Jest	Vitest
1	3.287s	2.575s	1.690s
2	3.295s	2.564s	1.770s
3	3.279s	2.589s	1.711s
4	3.311s	2.555s	1.708s
5	3.291s	2.567s	1.757s

Averages:

Slow Jest: 3.293s
Fast Jest: 2.570s
Vitest: 1.727s

Comparing with the best time from Jest, Vitest is 32% faster. When we look at our initial test case, the gain is 50%.

I hope you enjoyed this! Feel free to leave suggestions and share it with your friends and colleagues.

Criando sua API com Fastify e Prisma

Vinicius Rodrigues — Sun, 24 Mar 2024 19:19:10 +0000

Vinicius Rodrigues - Fullstack Developer - LinkedIn

Se você está lendo isso eu imagino que queira ter um primeiro contato com o Fastify ou esteja com alguma dúvida para iniciar o desenvolvimento da sua aplicação, sendo assim vamos direto ao ponto:

Fastify

O Fastify é um framework assim como o express que nos fornece um servidor http, é a base do nosso projeto e o que vai nos permitir criar nossa API de forma extremamente simples. Dentre as funcionalidades do Fastify creio que devemos abordar os Hooks, Decorators e Plugins

Hooks

Se você já construiu uma API já deve ter utilizado um middleware e esses "hooks" como o Fastify chama são nada mais do que middlewares. Você deve estar pensando na inutilidade disso agora mas não é bem assim, com os hooks podemos atribuir globalmente as nossas rotas todo tipo de tratamento ao qual nos for necessário. Mais a frente vamos ver um exemplo prático, por enquanto deixo este aqui:

fastify.addHook('preHandler', (request, reply, done) => {
  console.log('Antes de lidar com a requisição');
  done();
});

Decorators

Decorators em geral são funções usadas para adicionar funcionalidades em outro código, os decorators do Fastify não fogem desse conceito pois basicamente são uma extensão da instância do Fastify.

// Criação do decorator 'uppercase'
fastify.decorate('uppercase', function (value) {
  return value.toUpperCase();
});

fastify.get('/uppercase/:text', (request, reply) => {
// Usando o decorator 'uppercase' para converter 
// o parâmetro da rota para maiúsculas
  const uppercaseText = request.uppercase(request.params.text);
  reply.send({ uppercaseText });
});

Sendo assim, onde você tiver acesso a instância do fastify também será possível acessar todos os decorators.

Plugins

Aqui nos deparamos com um dos principais conceitos do fastify, pense no plugin como uma peça de lego que sozinha pode não fazer muito sentido, cada peça tem seu formato, cor, encaixe... e os plugins podem ter diferentes funcionalidades, vou deixar uns exemplos:

Handler de erros
Rotas http
Plugin de internacionalização
Conexão com bancos de dados

Mão na massa

Instale o Fastify, fastify-plugin e Prisma

pnpm add fastify fastify-plugin prisma

Crie o arquivo app.ts, aqui vamos inicializar nosso servidor.

// src/app.ts
import fastify from 'fastify'
import { dbPlugin } from './plugins/db-plugin'

// Registrar plugin do prisma
fastify.register(dbPlugin)

// Rota simples
fastify.get('/', (request, reply) => {
  reply.send({ hello: 'world' });
});

fastify.listen(3000, (err) => {
  if (err) {
    console.error(err);
    process.exit(1);
  }
  console.log('Servidor rodando em http://localhost:3000');
});

Feito isso, precisamos criar nosso plugin db-plugin onde estará o prisma client.

// src/plugins/db-plugin.ts

import fp from 'fastify-plugin';
import { PrismaClient } from '@prisma/client';

async function prismaPlugin(fastify, options) {
  const db = new PrismaClient();

  // Adiciona o objeto Prisma Client ao fastify, para que 
  // possa ser acessado em rotas e outros plugins
  fastify.decorate('db', db);

  // Se você quiser pode adicionar um **hook** para ter 
  // acesso ao **db** dentro do objeto de request.
  fastify.addHook('onRequest', (req, reply, done) => {
    req.db = db
    done();
  });

  // Fecha a conexão do Prisma Client quando o aplicativo 
  // Fastify é fechado
  fastify.addHook('onClose', async (fastifyInstance) => {
    fastifyInstance.db.$disconnect();
  });
}

export default fp(prismaPlugin);

O que eu fiz com o prisma pode ser feito com qualquer outra conexão com o banco, seja outro ORM, QueryBuilder ou o driver nativo. O mesmo vai ser aplicado pra diversas outras coisas, como um tratamento de logs, uma classe de erros global ou uma conexão com outro serviço.

Espero ter ajudado com esse pequeno artigo, tenho um projeto onde apliquei esses conceitos então vou deixa-lo aqui

Criando classes dinâmicas com SCSS.

Vinicius Rodrigues — Mon, 27 Jun 2022 02:19:42 +0000

Classes dinâmicas

O problema

Para começar, vou te sugerir um problema. Você está criando um arquivo de estilos padrão, nele você quer ter classes básicas para acelerar o desenvolvimento. Se fosse fazer isso da forma mais simples (e trabalhosa) as classes personalizadas de um margin-left ficariam mais ou menos assim:

.ml-1{
  margin-left: 4px;
}
.ml-2{
  margin-left: 8px;
}
.ml-3{
  margin-left: 12px;
}

(Note que para cada número estou adicionando 4px. Esse é o padrão de spacing do vuetify, ferramenta que uso atualmente e que motivou esse artigo.)

Nesse caso, além de escrever muitas classes (até onde iria? ml-16?) ainda criaríamos um problema, e se um dia por exemplo eu precisar mudar meu padrão de 4px para 2px? Sim, precisaríamos alterar todas as classes!!!

Mas calma, somos uma civilização avançada e temos frameworks que entregam muitas e muitas classes com muitas alternativas. O Bootstrap e o Vuetify que citei antes são bons exemplos. Porém nem todos os casos estão cobertos, no vuetify por exemplo não tenho a opção de usar o gap dinamicamente, olha uma tentativa de gap com 8px aí:

<div class="gap-2">
 ...
</div>

Como o vuetify não me entrega isso nativamente então terei que criar, sendo assim vamos botar a mão na massa.

A solução

Para começar, vamos precisar adicionar no nosso arquivo .scss algo que percorra uma lista de números e gere algo a partir dela. Simplificando, vamos fazer um for.

@for $i from 0 through 16 {
  ...
}

E agora precisamos definir nossa classe, vou chamar ela de flex-gap mas fique a vontade para definir outro nome.

@for $i from 0 through 16 {
  .flex-gap-#{$i} {
    gap: #{$i * 4}px;
  }
}

Lembra da regra dos 4px? ela está sendo aplicada ali no nosso loop, por exemplo, na posição 1 do nosso loop teremos:

i = 1
nome da classe = .flex-gap-1
gap = 4px

Nesse caso, teremos nossas 16 classes em apenas algumas linhas de código. Sem contar que teremos a classe flex-gap-0, você poderia usá-la para remover o gap de algum elemento caso necessário.

Agora é só usar sua classe customizada! Você pode ver um exemplo funcional aqui.

Se isso te ajudou deixa um comentário aí e fique a vontade pra me dar um oi no Linkedin

Padronize seus commits com Commitlint + Husky + Commitizen.

Vinicius Rodrigues — Mon, 21 Mar 2022 04:17:33 +0000

Antes de iniciarmos, é importante que você crie um projeto qualquer. Crie uma nova pasta, inicialize com npm init e logo após execute o git init. Com isso feito teremos o básico para iniciar. Aqui a intenção é dar os primeiros passos então o artigo vai focar na instalação e configuração das libs, no final irei indicar alguns links para que possa se aprofundar mais.

📖 Estrutura do Commit

Aqui seguiremos o padrão adotado pelo conventional commits.

📗 Commitlint

Commitlint cria regras e padrões para nossos commits, ele impedirá que o commit esteja fora do padrão proposto na sessão anterior.

⚙️ Instalação

npm i @commitlint/config-conventional @commitlint/cli -D

⚙️ Configuração

Após a instalação ser realizada, é necessário criar o arquivo commitlint.config.js com o conteúdo abaixo:

module.exports = { 
    extends: ['@commitlint/config-conventional'] 
};

Para que o commitlint consiga “interceptar” um commit iremos utilizar o Husky.

📗 Husky

⚙️ Instalação

npm i husky -D

⚙️ Configuração

npx husky install

npx husky add .husky/commit-msg 'npx --no -- commitlint --edit $1'

Após isso ao utilizar o comando “git commit” o husky irá solicitar a validação do commitlint e nosso commit só será aceito se estiver dentro das regras.

Para nos ajudar a não criar commits fora das regras iremos utilizar uma ferramenta chamada commitzen.

📗 Commitizen

⚙️ Instalação

npm i -D commitizen

⚙️ Configuração

Adicione a configuração do conventional commits para que o commitizen siga esse padrão. Basta executar o comando abaixo:

npx commitizen init cz-conventional-changelog --save-dev --save-exact

Após isso temos que adicionar um novo script, podemos chama-lo de “commit” assim continuaremos utilizando um comando parecido para fazer o fluxo que estamos acostumados. Adicione o seguinte conteúdo no seu package.json.

"scripts": {
    "commit": "cz"
 }

A partir de agora nosso fluxo de commits deixa de usar o comando “git commit” e passa a utilizar o “npm run commit”. Nesse caso, iremos executar o commitzen que por sua vez fará o commit, o husky irá intervir e utilizar o commitlint para realizar a validação.

Pronto!!! Está tudo padronizado e pronto para ser utilizado. Mas tenho que te informar que essas ferramentas vão muito além e você mesmo pode criar um padrão personalizado de acordo com suas regras. Se quiser se aprofundar os links das documentações de cada uma das bibliotecas e um outro artigo que mostra a instalação das ferramentas com yarn estão logo abaixo.

DEV Community: Vinicius Rodrigues

Maximize a Performance dos Seus Testes com Jest e Vitest

Introdução

O cenário caótico

Otimizando o Jest

Otimizando o teste

Expandindo os horizontes com Vitest

Speed Up Your Tests with Jest and Vitest

Introduction

The Chaotic Scenario

Otimizando o Jest

Optimizing Jest

Optimizing the Test

Expanding Horizons with Vitest

Criando sua API com Fastify e Prisma

Fastify

Hooks

Decorators

Plugins

Mão na massa

Criando classes dinâmicas com SCSS.

Classes dinâmicas

O problema

A solução

Padronize seus commits com Commitlint + Husky + Commitizen.

📖 Estrutura do Commit

📗 Commitlint

⚙️ Instalação

⚙️ Configuração

📗 Husky

⚙️ Instalação

⚙️ Configuração

📗 Commitizen

⚙️ Instalação

⚙️ Configuração

🌐 Links úteis