DEV Community: Ágatha

FIRST Principles and Test Smells 🚀

Ágatha — Sat, 04 May 2024 18:53:35 +0000

When it comes to writing high-quality unit tests, there are some basic principles, grouped under the acronym FIRST, that can be quite helpful.

Fast ⚡

Unit tests should always be fast. The idea is that you can run them all the time, without having to wait. If you need a coffee while your tests run, they probably aren't fast enough.

Independent 🧍

Each unit test should be able to stand on its own. It doesn't matter in what order you decide to run them; they should not depend on each other.

Repeatable 🔁

If you run the same test multiple times, the outcome should always be the same: either the test always passes or always fails. Tests that sometimes pass and sometimes fail without any apparent reason are called "flaky" or erratic.

Self-checking ✅

Once the test execution is complete, the result should be self-explanatory (passed/failed). This way, the outcome can be quickly verified and interpreted.

Timely 🕰️

It's a good idea to write your unit tests as early as possible in your development process. Many people even prefer to write the tests before the code they will test; this helps ensure that your code will do exactly what you expect from the start.

Test Smells 🐟👃

Some signs in your test code may indicate that something could be improved. These signs are called "Test Smells":

Obscure Test 🌫️🤔

In code, an "Obscure Test" is complicated, long, and difficult to understand. Tests should be simple and straightforward so that anyone can understand what is being tested and why. It is important to have a clear and easy-to-understand logic.

Test with Conditional Logic ➰❓

A test with many "ifs" and "elses" makes it difficult to understand exactly what is being tested and under what conditions. Ideally, unit tests should be linear; conditional logic in tests hampers understanding.

Code Duplication in Tests 📄🚫

If you have repeated code in several tests, there might be a more efficient way to organize this.

Test Smells are like a signal that maybe you can simplify or better organize your tests. It's not that you can never have an "if" in a test or a slightly longer test, but it's a reminder to stop and think: "Is there a simpler way to do this?”

Most of this content came from the book "Modern Software Engineering", written by Marco Tulio Valente. This book is a treasure trove of tips on how to create tests the right way, using the latest and most efficient in the programming world. However, the only difference is that the book is in Java and here I adapted it to use JavaScript.

Testes de Sistema 🌐

Ágatha — Sun, 07 Apr 2024 18:56:41 +0000

Testes de sistema são uma simulação completa de como um usuário real interage com o aplicativo, de ponta a ponta. São os testes mais abrangentes e, por isso, geralmente os mais caros e os que levam mais tempo para serem executados.

Para automatizar testes de sistemas Web em JavaScript, você pode usar ferramentas como Selenium ou alternativas modernas como Cypress ou Puppeteer. Essas ferramentas permitem que você escreva scripts de teste que interagem com o navegador, assim como um usuário real faria.

Exemplo: Teste de Sistemas Web 💻

Essa é a forma em como você poderia escrever um teste para uma pesquisa no Google usando Puppeteer, que é uma biblioteca Node.js para controlar navegadores Headless Chrome ou Chromium:

// googleSearch.test.js
const puppeteer = require('puppeteer');

describe('Google Search', () => {
  it('should search for "software"', async () => {
    const browser = await puppeteer.launch();
    const page = await browser.newPage();
    await page.goto('http://www.google.com');

    await page.type('input[name=q]', 'software');
    await page.keyboard.press('Enter');

    await page.waitForSelector('h3'); // Espera pelo carregamento dos resultados

    const pageTitle = await page.title();
    console.log(`Page title is: ${pageTitle}`);

    await browser.close();

    expect(pageTitle).toMatch('software - Google Search');
  }, 16000); // Aumentar o timeout para testes que podem levar mais tempo
});

Neste script, Puppeteer abre o navegador, vai para o Google, digita a palavra "software" na pesquisa, pressiona Enter e espera pelos resultados da pesquisa.

Exemplo: Teste de um Compilador 🛠️

Se você estivesse testando um compilador em JavaScript, o teste poderia ser mais direto porque você está apenas lidando com arquivos de entrada e saída, não uma interface de usuário.

// compiler.test.js
const { compile } = require('./compiler');
const fs = require('fs');

describe('Compiler Tests', () => {
  it('should compile program correctly', async () => {
    const inputProgram = 'path/to/program.x';
    const expectedOutput = 'expected program output';

    await compile(inputProgram);

    const output = fs.readFileSync('path/to/output', 'utf8');
    expect(output).toBe(expectedOutput);
  });
});

Aqui, o compile é uma função que você escreveria para pegar o caminho para um arquivo de programa, compilar esse programa e, em seguida, você verificaria a saída contra o esperado.

Considerações 🤔

Testes de sistema devem refletir cenários de uso reais;
Mudanças na interface do usuário ou nos sistemas externos podem quebrar seus testes, então eles precisam ser mantidos atualizados;

A maior parte desse conteúdo veio do livro "Engenharia de Software Moderna", escrito por Marco Tulio Valente. Esse livro é um tesouro cheio de dicas sobre como criar testes do jeito certo, usando o que tem de mais novo e eficiente no mundo da programação. Entretanto, a única diferença, é que o livro é em Java e aqui eu adaptei para utilizar Javascript.

Testes de Integração 🔗

Ágatha — Sun, 07 Apr 2024 18:43:47 +0000

O objetivo principal dos testes de integração é ter uma maior assertividade e conseguir interagir com o sistema real. Eles ajudam a garantir que as diversas partes do seu sistema como módulos individuais, serviços ou funções trabalhem juntas como esperado.

Ao invés de testar partes isoladas do código (como funções individuais ou classes), é testado como diferentes partes funcionam juntas. Isso inclui interações com bancos de dados, APIs externas ou qualquer outro serviço que seu aplicativo use.

O objetivo desses testes é garantir que todos os módulos ou serviços do seu aplicativo trabalhem junto quando combinados, detectando problemas que podem não ser visíveis em testes de unidade.

Exemplo: Agenda de Compromissos 📅

Digamos que você está trabalhando em um sistema de agenda para gerenciar compromissos, e quer testar se a lógica de adicionar e listar compromissos está funcionando corretamente, incluindo a interação com um banco de dados real.

// Agenda.js
class Agenda {
  constructor(database) {
    this.database = database;
  }

  addAppointment(appointment) {
    // Código para adicionar um compromisso ao banco de dados
  }

  listAppointments() {
    // Código para listar compromissos do banco de dados
  }
}

module.exports = Agenda;

Em seguida, você escreve um teste de integração para verificar se a adição e listagem de compromissos estão funcionando como esperado:

// Agenda.test.js
const Agenda = require('./Agenda');
const Database = require('./Database'); // Uma classe que representa o seu banco de dados real

describe('Agenda Integration Test', () => {
  it('should add and list appointments', async () => {
    const database = new Database();
    const agenda = new Agenda(database);

    await agenda.addAppointment({ /* dados do compromisso */ });
    await agenda.addAppointment({ /* dados do compromisso */ });
    await agenda.addAppointment({ /* dados do compromisso */ });

    const appointments = await agenda.listAppointments();

    expect(appointments).toHaveLength(3);
  });
});

Importante: Nesse exemplo, você não usa mocks ou stubs, pois o objetivo é interagir com o sistema real, como um banco de dados. Assim, você terá uma instância real do banco de dados em seu teste, que deve estar configurado para um ambiente de teste, idealmente usando uma base de dados que possa ser limpa ou recriada antes de cada teste para garantir a consistência.

Testes de integração geralmente são mais lentos do que testes de unidade devido à sua complexidade e à necessidade de interagir com sistemas externos.

Ao executar testes de integração, você está verificando não apenas a lógica do negócio, mas também a integração dessa lógica com outras partes do sistema, assegurando que o sistema como um todo funcione conforme o esperado.

Desenvolvimento Dirigido por Testes (TDD) 🔁

Ágatha — Sun, 07 Apr 2024 18:18:07 +0000

Desenvolvimento Dirigido por Testes, ou TDD, é como fazer um plano antes de começar uma viagem. Você decide para onde quer ir (o que quer que seu código faça), verifica se chegou lá (testa seu código), e se não, você descobre um caminho (escreve o código para fazer o teste passar). Depois, você olha ao redor para ver se pode melhorar algo na rota que escolheu (refatora o código).

Com TDD, você começa escrevendo um teste para a funcionalidade que quer adicionar ou o bug que precisa consertar. No início, esse teste vai falhar porque você ainda não escreveu o código que faz o que o teste espera, e isso é bom, por que significa que você tem uma meta clara.

A próxima etapa é escrever o código que satisfaz esse teste. Inicialmente, você pode até fazer algo bem simples, só para ver o teste passar. Isso pode parecer um pouco ao contrário, mas tem um bom motivo: ajuda a garantir que seu código só faz o que é realmente necessário e nada mais.

Depois que o teste passa, você tem a oportunidade de melhorar seu código, deixando-o mais limpo, organizado e eficiente. Isso é a refatoração. Como você tem os testes, pode refazer seu código com segurança, sabendo que se algo quebrar, os testes vão te avisar.

Por fim, TDD não é só sobre testar ou não esquecer de escrever testes. É uma forma de pensar sobre o design do seu software desde o início. Quando você escreve o teste primeiro, está pensando na interface e na usabilidade do seu código antes mesmo de implementá-lo. Isso pode levar a um design melhor e mais limpo.

Testes Falhando 🔴

Você começa escrevendo um teste para a funcionalidade que quer criar, e esse teste vai falhar porque a funcionalidade ainda não existe. Isso é ótimo, porque agora você tem um claro ponto de partida e sabe exatamente o que seu código precisa alcançar. Aqui você também cria um esqueleto básico da sua classe ou função, só para o teste conseguir compilar.

Testes Passando ✅

Agora é hora de fazer o teste passar, escrevendo código que atenda ao que o teste espera. No começo, o código pode ser relativamente bem simples. Não precisa ser perfeito, só precisa ver o teste ficar verde, mostrando que a funcionalidade básica está funcionando.

Refatoração ♻️

Com os testes passando, você dá uma olhada crítica no seu código e vê como pode melhorá-lo sem mudar o que ele faz. Você remove redundâncias, limpa o código, e faz ajustes que deixam o código mais claro e fácil de manter.

Exemplo: Carrinho de Compras 🛒

Imagine que você tem um objeto Book com propriedades como título, ISBN e preço, e um objeto ShoppingCart onde você pode adicionar livros, calcular o preço total e remover livros.

Estado Vermelho 🚩: Primeiro, você escreve um teste para a nova funcionalidade do seu carrinho de compras. Inicialmente, esse teste vai falhar porque ShoppingCart ainda não tem o método add ou getTotal.

// ShoppingCart.test.js
const ShoppingCart = require('./ShoppingCart');
const Book = require('./Book');

describe('ShoppingCart', () => {
  it('calculates total price for books in the cart', () => {
    const book1 = new Book("book1", 10, "1");
    const book2 = new Book("book2", 20, "2");
    const cart = new ShoppingCart();
    cart.add(book1);
    cart.add(book2);
    expect(cart.getTotal()).toBe(30);
  });
});

Estado Verde 🟢: Depois, você implementa o mínimo necessário para fazer o teste passar. Aqui está uma implementação inicial para a classe ShoppingCart e a classe Book.
Com isso, quando você rodar o teste novamente, ele deve passar, porque ShoppingCart agora realiza a funcionalidade básica esperada.

// Book.js
class Book {
  constructor(title, price, isbn) {
    this.title = title;
    this.price = price;
    this.isbn = isbn;
  }
}

module.exports = Book;

// ShoppingCart.js
class ShoppingCart {
  constructor() {
    this.items = [];
    this.total = 0;
  }

  add(book) {
    this.items.push(book);
    this.total += book.price;
  }

  getTotal() {
    return this.total;
  }
}

module.exports = ShoppingCart;

Estado Amarelo 🟡: Pode ser interessante garantir que as propriedades do Book sejam privadas e acessíveis apenas através de métodos getters e setters.
Aqui está como poderia ser a refatoração da classe Book:

// Book.js (refatorado)
class Book {
  constructor(title, price, isbn) {
    this._title = title;
    this._price = price;
    this._isbn = isbn;
  }

  get title() {
    return this._title;
  }

  get price() {
    return this._price;
  }

  get isbn() {
    return this._isbn;
  }
}

module.exports = Book;

Após a refatoração, você deve rodar os testes novamente para garantir que tudo ainda está funcionando como deveria. Isso completa um ciclo de TDD. Agora, você pode adicionar mais funcionalidades ao carrinho, como remover itens, e para cada nova funcionalidade, você começaria um novo ciclo de TDD.

Mocks vs Stubs 🤼

Ágatha — Sat, 06 Apr 2024 19:35:24 +0000

Mocks são ferramentas úteis para simular comportamentos de partes do seu código que dependem de sistemas externos ou complexos, permitindo testar seu código de forma isolada e eficiente. Usar mocks ajuda a manter seus testes de unidade rápidos e focados apenas no que você quer testar, sem depender de serviços de rede, bancos de dados ou qualquer outro recurso externo.

Exemplo 📖

Uma classe para pesquisa de livros, que interage com um serviço externo, neste cenário, temos uma função getBook que busca dados de um livro por meio de uma API externa.

// BookSearch.js
class BookSearch {
  constructor(bookService) {
    this.bookService = bookService;
  }

  async getBook(isbn) {
    const json = await this.bookService.search(isbn);
    const data = JSON.parse(json);
    return { titulo: data.titulo };
  }
}

module.exports = BookSearch;

Problema 🚧

Para testar BookSearch isoladamente, precisamos de um bookService, que é um serviço externo. Testar diretamente com o serviço real tornaria o teste lento e instável, pois depende de uma rede e de um serviço que pode não estar sempre disponível ou responder de forma consistente.

Solução 🌟

Para resolver esse problema, podemos criar um mock para BookService. Em JavaScript, isso pode ser feito facilmente com o auxílio de bibliotecas de testes como Jest, que oferecem suporte embutido para criar mocks.

// MockBookService.js
class MockBookService {
  async search(isbn) {
    if (isbn === 1234) {
      return JSON.stringify({ titulo: "Eng Soft Moderna" });
    }
    return JSON.stringify({ titulo: "NULL" });
  }
}

module.exports = MockBookService;

E o teste poderia ser escrito assim:

// BookSearch.test.js
const BookSearch = require('./BookSearch');
const MockBookService = require('./MockBookService');

describe('BookSearch', () => {
  test('getBook returns correct title', async () => {
    const service = new MockBookService();
    const bookSearch = new BookSearch(service);
    const book = await bookSearch.getBook(1234);
    expect(book.titulo).toBe('Eng Soft Moderna');
  });
});

Neste cenário, o mock MockBookService simula a resposta de uma API externa sem realmente fazer uma chamada de rede. Isso mantém o teste rápido e independente do ambiente externo. Embora não estejamos testando a interação real com o serviço externo, o mock nos permite verificar se BookSearch está processando corretamente o JSON retornado e criando o objeto Book como esperado. Assim, podemos focar no teste da lógica interna de BookSearch, garantindo que ela funciona corretamente, independentemente da confiabilidade ou disponibilidade do serviço externo.

Mocks vs Stubs 🤼

Mocks: São objetos que simulam o comportamento de objetos reais de maneira controlada. Em testes de unidade, os mocks são usados para verificar interações entre partes do código, ou seja, eles podem ser utilizados para garantir que certas funções foram chamadas, com quais parâmetros foram chamadas, e quantas vezes. Isso está relacionado ao teste do comportamento do código.
Stubs: São simplificações de objetos que substituem funcionalidades que não são o foco do teste. Eles oferecem respostas predefinidas a chamadas específicas. Diferente dos mocks, os stubs não são usados para verificar interações ou comportamentos. Eles são mais sobre fornecer um ambiente de teste controlado ao substituir partes do sistema que estão fora do escopo do teste atual.

Em JavaScript, usando Jest como exemplo, você pode criar tanto mocks quanto stubs de maneira simples.

Exemplo 📖

Vamos considerar um exemplo simples onde temos uma função de negócio que depende de um serviço de envio de emails. Usaremos Jest para demonstrar tanto o conceito de mock (verificando o comportamento) quanto de stub (substituindo uma dependência complexa por uma versão simplificada).

Criando um Mock 🎭

Supondo que temos uma classe Mailer que queremos mockar:

class Mailer {
  send(email) {
    // Lógica de envio de email
  }
}

E um SUT que usa Mailer:


function someBusinessLogic(mailer, message) {
  mailer.send(message);
}

Podemos usar Jest para mockar Mailer e verificar se send foi chamado:


const mailer = new Mailer();
jest.mock('./Mailer');

test('verifies Mailer.send is called', () => {
  someBusinessLogic(mailer, "Hello");
  expect(mailer.send).toHaveBeenCalledWith("Hello");
});

Criando um Stub 📌

Se, ao contrário, só precisássemos de um Mailersimplificado que não fizesse nada (apenas satisfazendo o tipo esperado sem influenciar o teste), poderíamos criar um stub assim:

const mailerStub = {
  send: jest.fn() // Isso cria um stub que satisfaz a interface mas não faz nada
};

Embora a distinção entre mocks e stubs possa ser sutil, entender quando usar cada um pode ajudar a escrever testes mais claros e focados. Em JavaScript, com ferramentas como Jest, criar e usar mocks e stubs é bastante direto, facilitando a implementação de testes de unidade eficazes que podem verificar comportamentos específicos (mocks) ou apenas substituir partes do sistema para isolamento (stubs).

Exemplo: Criando API em JavaScript 🌐

Primeiro, temos um simples endpoint que calcula o IMC:


// IMCController.js
const express = require('express');
const app = express();
app.use(express.json());

const IMCModel = {
  calculaIMC(peso, altura) {
    return peso / (altura * altura);
  }
};

app.get('/imc', (req, res) => {
  const { peso, altura } = req.query;
  const imc = IMCModel.calculaIMC(parseFloat(peso), parseFloat(altura));
  res.send({ imc: `IMC: ${imc}` });
});

module.exports = app; // Para permitir importação no teste

Usando Jest, podemos testar essa API sem precisar fazer chamadas reais. Jest nos permite mockar partes do Express para simular requisições e respostas.

// IMCController.test.js
const request = require('supertest');
const app = require('./IMCController');

describe('GET /imc', () => {
  it('calculates IMC correctly', async () => {
    const response = await request(app).get('/imc?peso=82&altura=1.80');
    expect(response.text).toEqual("{\"imc\":\"IMC: 25.30864197530864\"}");
  });
});

No exemplo acima, não precisamos de mocks para req e res porque o supertest cuida disso, permitindo que façamos chamadas ao nosso app Express como se fossem chamadas reais, mas tudo é simulado e nada vai para uma rede real.

Em JavaScript, o uso de mocks e stubs é simplificado por bibliotecas como Jest, que permitem a você focar na lógica dos testes sem se preocupar com a complexidade de criar e gerenciar esses objetos dublês.

No entanto, cuidado: o uso de mocks pode aumentar o acoplamento entre os testes e a implementação, tornando os testes frágeis a mudanças internas. Portanto, é importante usar mocks com cautela e sempre ponderar sobre a melhor abordagem para cada situação de teste.

Testabilidade em Javascript 🧪

Ágatha — Sat, 06 Apr 2024 19:08:24 +0000

Testabilidade é sobre o quão fácil é escrever testes para um pedaço do seu código. Para que um código seja fácil de testar, ele precisa ser bem organizado e seguir bons princípios de design, como ter funções com responsabilidades claras e separadas, evitar dependências complicadas entre partes do código e outras boas práticas de programação.

Exemplo: Cálculo de IMC 📏👤

Num cenário inicial complicado para testes, poderia existir um cáculo de IMC, e todo o cálculo e interação com o usuário, estar tudo misturado numa única função ou módulo. Isso faria com que testar o cálculo do IMC fosse difícil, pois você teria que simular toda a interação do usuário.

Para melhorar a testabilidade, o melhor seria separar a lógica do cálculo do IMC em um módulo separado, deixando a interação com o usuário para outra parte do código. Isso torna muito mais simples escrever testes unitários para a lógica do IMC, pois você pode testá-la diretamente sem se preocupar com as partes de interação do usuário.

// IMCModel.js
class IMCModel {
  calculaIMC(peso, altura) {
    return peso / (altura * altura);
  }
}

module.exports = IMCModel;

E então, em outra parte do código, lidar com a interação do usuário:

// IMCController.js
const IMCModel = require('./IMCModel');
const model = new IMCModel();

function calculaEExibeIMC(peso, altura) {
  const imc = model.calculaIMC(peso, altura);
  console.log(`Índice de Massa Corporal (IMC): ${imc}`);
}

calculaEExibeIMC(70, 1.75);

Nesse exemplo, IMCModel contém apenas a lógica para calcular o IMC, tornando-a fácil de testar de forma isolada. Não é necessário se preocupar com detalhes de como o peso e a altura são obtidos ou como o resultado é exibido. Essa separação de responsabilidades melhora a testabilidade do código.

Essa abordagem mostra como o design do código influencia diretamente na facilidade de testá-lo. Separar a lógica de domínio da apresentação não só torna seu código mais limpo e organizado, mas também muito mais fácil de testar.

Exemplo: Chamada Assíncrona ⏳🔄

Trabalhar com código assíncrono é algo bem comum, especialmente quando se trata de operações como chamadas de rede, leituras de arquivo, ou qualquer tarefa que leve tempo para ser concluída. Isso torna o teste dessas funções um pouco mais desafiador, mas não impossível.
Vamos começar com uma classe MyMath que contém uma função assíncrona para calcular PI e uma versão síncrona dessa mesma função para facilitar os testes:

class MyMath {
  // Função síncrona que calcula PI.
  syncPI(prec) {
    let pi = 0;
    for (let k = 0; k < prec; k++) {
      pi += Math.pow(-1, k) / (2 * k + 1);
    }
    return pi * 4;
  }

  // Função assíncrona que utiliza a versão síncrona para calcular PI.
  async asyncPI(prec) {
    return new Promise((resolve) => {
      setTimeout(() => {
        const pi = this.syncPI(prec);
        resolve(pi);
      }, 1000); // Simula um cálculo que leva tempo com setTimeout.
    });
  }
}

module.exports = MyMath;

Testando o Código Assíncrono em JavaScript:

const MyMath = require('./MyMath');
const myMath = new MyMath();

describe('MyMath', () => {
  test('asyncPI returns the correct PI value', async () => {
    const prec = 10; // Define a precisão como exemplo.
    const piValue = await myMath.asyncPI(prec);
    expect(piValue).toBe(3.0418396189294032);
  });
});

Neste teste, você usa async/await para esperar a promessa retornada por asyncPI ser resolvida. Jest espera automaticamente pela resolução da promessa quando você declara a função de teste com async.

Isso mostra uma abordagem prática para melhorar a testabilidade de código assíncrono: separar a lógica complexa em funções síncronas que podem ser testadas independentemente e, em seguida, usar essas funções em operações assíncronas. Esse método não apenas torna seu código mais testável, mas também o mantém organizado e fácil de entender.

Princípios FIRST e Test Smells 🚀

Ágatha — Sat, 06 Apr 2024 17:53:36 +0000

Quando se fala em escrever testes de unidade de boa qualidade, há alguns princípios básicos, agrupados na sigla FIRST, que podem ajudar bastante.

Fast ⚡

Os testes de unidade devem sempre ser rápidos. A ideia é que você consiga rodá-los o tempo todo, sem ficar esperando. Se você precisa de um café enquanto seus testes rodam, provavelmente eles não são rápidos o suficiente.

Independent 🧍‍♂️

Cada teste de unidade deve ser capaz de se virar sozinho. Não importa a ordem que você decide rodá-los; eles não devem depender uns dos outros.

Repeatable 🔁

Se você rodar o mesmo teste várias vezes, o resultado deveria ser sempre o mesmo: ou o teste sempre passa, ou sempre falha. Testes que às vezes passam e às vezes falham sem motivo aparente são chamados de "flaky" ou erráticos.

Self-checking ✅

Uma vez finalizada a execução dos testes, o resultado deve ser auto-explicativo (passou/falhou). Desta forma, o resultado pode ser ligeiramente verificado e interpretado.

Timely 🕰️

É uma boa ideia escrever os testes de unidade o quanto antes no seu processo de desenvolvimento. Muita gente até prefere escrever os testes antes do código que eles vão testar, isso ajuda a garantir que o seu código vai fazer exatamente o que você espera desde o começo.

Test Smells 🐟👃

Alguns sinais no seu código de teste podem indicar que algo pode melhorar. Esses sinais são chamados de "Test Smells":

Teste Obscuro 🌫️🤔

No código, um "Teste Obscuro" é assim: complicado, longo e difícil de entender. Testes devem ser simples e diretos, para que qualquer pessoa possa entender o que está sendo testado e por quê. É importante ter uma lógica clara e de fácil entendimento.

Teste com Lógica Condicional ➰❓

Um teste com muitos "se" e "senão" torna difícil de entender exatamente o que está sendo testado e em que condições. O ideal é que os testes de unidades sejam lineares, lógica condicional em testes prejudica o entendimento.

Duplicação de Código em Testes 📄🚫

Se você tem código repetido em vários testes, talvez haja uma maneira mais eficiente de organizar isso.

Test Smells são como um sinal de que talvez você possa simplificar ou organizar melhor seus testes. Não é que você nunca possa ter um "se" num teste ou um teste um pouco mais longo, mas é um lembrete para parar e pensar: "Tem um jeito mais simples de fazer isso?”

Quando Escrever Testes de Unidade?💡

Ágatha — Sat, 06 Apr 2024 17:47:50 +0000

Escrever testes de unidade é como se preparar para uma prova: você estuda um tópico e faz um teste para ver se realmente aprendeu. Existem duas formas principais de fazer isso:

Depois de Programar: Você cria uma parte do seu programa, como uma função que soma dois números. Depois de fazer isso funcionar, você escreve um teste que verifica se, quando você soma 2 e 2, o resultado é realmente 4. Você continua assim, criando mais partes do seu programa e escrevendo testes para cada uma.
Antes de Programar (TDD): Esse é o método Test-Driven Development (Desenvolvimento Orientado por Testes). Aqui você faz ao contrário: escreve o teste para a função de soma antes mesmo de fazer a função. Claro, o teste vai falhar, porque a função ainda não existe. Depois, você cria a função de forma que faça o teste passar. Isso ajuda a manter o foco em fazer apenas o necessário para que a função cumpra sua tarefa.

Além de escrever testes antes ou depois de desenvolver, tem mais duas maneiras inteligentes de usar os testes de unidade:

Quando Aparecer um Bug: Imagine que alguém te conta que encontrou um erro no seu programa. Uma ótima maneira de começar a resolver isso é escrevendo um teste que mostra esse erro acontecendo. Assim, você tem um teste que falha porque o programa não está fazendo o que deveria. Depois, você conserta o erro e, se o teste passar, você não só corrigiu o problema como também ganhou um novo teste para garantir que esse erro não volte a acontecer no futuro.
Durante a Depuração: Se você está tentando entender por que uma parte do seu programa não está funcionando, resistir à tentação de só jogar um monte de console.log para ver o que está acontecendo. Em vez disso, é melhorar escrever um teste que verifica o comportamento que você está tentando consertar. Isso te ajuda a ser mais sistemático na depuração e ainda te deixa com um teste útil no final.

E sobre quando não escrever testes de unidade?

Não deixe para o final: Esperar até que todo o programa esteja pronto para começar a testar geralmente não é uma boa ideia. Isso porque você pode acabar fazendo os testes com pressa e de forma superficial, ou pior, pode acabar não fazendo os testes de jeito nenhum. Além disso, testar tudo de uma vez pode ser muito mais complicado e menos eficiente do que testar pedacinho por pedacinho à medida que você constrói o programa.
Não divida a responsabilidade: É tentador pensar que alguém pode fazer o programa e outra pessoa pode testá-lo. Mas na verdade, é super importante que quem escreveu um pedaço do código também escreva os testes para esse código. Isso ajuda a garantir que os testes estão cobrindo o que realmente importa e que o desenvolvedor entende profundamente como seu código deve funcionar.

Por fim, usar testes de unidade ao longo do desenvolvimento do seu programa não só ajuda a encontrar e corrigir problemas mais rápido, mas também te dá a segurança de que as mudanças que você faz não quebram coisas que já estavam funcionando.

Benefícios 🚀

Encontrar Bugs Cedo: A ideia é pegar os problemas enquanto você ainda está desenvolvendo, antes de tudo ficar mais complicado (e caro) para consertar. Se você tem bons testes, é menos provável que erros chatos surpreendam você ou seus usuários lá na frente.
Evitar Regressões: Uma "regressão" é quando você muda alguma coisa no código para melhorar ou adicionar algo novo, mas acaba estragando outra coisa sem querer. Com testes de unidade, se você fizer uma mudança que cause uma regressão, provavelmente vai descobrir rápido porque um dos seus testes vai falhar.
Documentar e Especificar: Além de te ajudar a não quebrar coisas, os testes também contam uma história sobre como seu código deve se comportar. Se alguém quiser entender melhor uma parte do seu programa, pode começar olhando os testes para ver o que esperar dele. É quase como se os testes fossem um manual de instruções que mostra como usar e o que esperar do seu código.

Mas e no mundo real? Empresas gigantes como Google e Facebook levam os testes de unidade super a sério. No Google, por exemplo, eles não deixam nem o código entrar sem ter testes junto. Eles acham tão importante que têm até ferramentas que te lembram de escrever os testes. No Facebook, os engenheiros também são responsáveis por testar seus próprios códigos e por garantir que novas mudanças não quebrem nada que já estava funcionando.

Então, os testes de unidade não são só uma coisa teórica legal para "projetos escolares". Eles são usados o tempo todo, em grandes projetos reais, para manter tudo funcionando suavemente e para evitar surpresas desagradáveis.

Introdução a Testes de Unidade com Javascript 📘

Ágatha — Sat, 06 Apr 2024 17:33:08 +0000

Testes Automatizados 🤖

Fazer testes manualmente, ou seja, uma pessoa sentar e testar tudo passo a passo, leva muito tempo, custa caro e é um trabalho que ninguém quer fazer. Além disso, sempre que algo no programa muda, tem que testar tudo de novo…
Para entender melhor os testes automatizados, existe uma coisa chamada pirâmide de testes, que foi uma ideia do Mike Cohn.
Imagine uma pirâmide dividida em partes, onde cada parte mostra um tipo diferente de teste, organizados do mais simples e rápido lá embaixo até os mais complexos e demorados no topo. Essa pirâmide ajuda a entender que não todos os testes são iguais: alguns são básicos e outros são bem detalhados, mas todos são importantes para garantir que o programa funcione direitinho.

Na base da pirâmide, temos os testes de unidade. Eles são como checar as peças de um quebra-cabeça uma por uma para ter certeza de que cada uma está certa. Cada teste desses olha para uma pequena parte do programa (geralmente uma única função ou classe) para ver se ela está fazendo o que deveria. Esses testes são muitos, rápidos de rodar e fáceis de fazer.

No meio da pirâmide, encontramos os testes de integração ou testes de serviços. Imagine tentar ver se algumas peças do quebra-cabeça se encaixam como deveriam. Estes testes olham como diferentes partes do programa trabalham juntas. Por exemplo, eles podem testar se o programa salva as informações certinho no banco de dados. Esses testes são um pouco mais complexos que os testes de unidade e demoram mais para serem feitos e rodados.

No topo da pirâmide, temos os testes de sistema ou testes de interface com o usuário. Isso é como pegar o quebra-cabeça montado e ver se a imagem final está certa. Estes testes verificam o programa inteiro, de ponta a ponta, do jeito que um usuário de verdade usaria. São os testes mais complexos, mais demorados para rodar e custam mais caro. Eles também são "frágeis", o que quer dizer que pequenas mudanças no programa podem fazer com que esses testes precisem ser ajustados.

Uma recomendação genérica é que esses três testes sejam implementados na seguinte proporção: 70% como testes de unidades; 20% como testes de serviços e 10% como testes de sistema.

Testes de Unidade 🧪

Os testes de unidade são como mini-testes para pedacinhos do seu programa. Imagine que seu programa é um robô, e cada teste de unidade verifica se uma parte específica do robô (como um braço ou uma roda) está funcionando direitinho. Você escreve um pequeno teste para cada classe do seu programa, que é basicamente um conjunto de instruções que o programa segue. Cada teste verifica se, ao pedir para essa classe fazer alguma coisa (como somar dois números), ela realmente faz isso certo.

Então, quando você olha para o seu programa, você tem duas grandes partes: as classes, que são como o coração do programa, fazendo todo o trabalho; e os testes de unidade, que são como um checklist para garantir que cada parte do programa está fazendo seu trabalho corretamente. É como se tivesse um manual de "como as coisas deveriam funcionar" e estivesse marcando cada item para ter certeza de que está tudo ok.

A figura ilustra um sistema com várias classes, que são como as diferentes partes de um programa, e os testes correspondentes a essas classes. Algumas classes têm mais de um teste associado a elas, o que geralmente acontece porque essas partes do programa são mais complexas ou críticas, então precisam ser testadas em mais situações para ter certeza de que estão sempre funcionando bem.

Por exemplo, a classe C1 é testada tanto por T1 quanto por T2, talvez ela tem um papel importante no programa e precisa ser muito bem verificada. Já a classe C2 não tem nenhum teste associado, o que pode significar que os desenvolvedores ainda não fizeram testes para ela ou talvez ela não seja tão essencial assim para o funcionamento geral do sistema.

Os testes de unidade são criados com a ajuda de ferramentas especiais chamadas frameworks xUnit. Esses frameworks são como kits de ferramentas que ajudam a criar e rodar os testes automaticamente. O "x" no xUnit é substituído pelo nome da linguagem de programação usada. Atualmente já existem versões de frameworks xUnit para as principais linguagens de programação.

Uma das vantagens de testes de unidade é que não é necessário aprender uma nova linguagem, por que os testes são implementados na mesma linguagem do sistema que se pretende testar. Assim, os desenvolvedores podem se concentrar em melhorar o programa, sem ter que gastar tempo extra aprendendo outras coisas só para testá-lo.

Para explicar os conceitos de testes de unidade, vamos usar uma classe Stack:

class Stack {
  constructor() {
    this.elements = [];
  }

  size() {
    return this.elements.length;
  }

  isEmpty() {
    return this.elements.length === 0;
  }

  push(elem) {
    this.elements.push(elem);
  }

  pop() {
    if (this.isEmpty())
      throw new Error('Stack is empty');
    return this.elements.pop();
  }
}

module.exports = Stack

const Stack = require('./stack');

describe('Stack', () => {
  let stack;

  beforeEach(() => {
    stack = new Stack();
  });

  test('pushes an element onto the stack', () => {
    stack.push(1);
    expect(stack.size()).toBe(1);
  });

  test('pops an element from the stack', () => {
    stack.push(2);
    expect(stack.pop()).toBe(2);
    expect(() => stack.pop()).toThrow('Stack is empty');
  });

  test('checks if the stack is empty', () => {
    expect(stack.isEmpty()).toBeTruthy();
  });
});

Usamos describe para agrupar testes relacionados a uma certa funcionalidade ou classe.
beforeEach é uma função que é executada antes de cada teste, configurando um ambiente limpo. Neste caso, estamos criando uma nova instância da pilha antes de cada teste.
test (ou it em algumas frameworks) é usado para definir um teste individual.
expect é uma função que verifica se o resultado corresponde ao esperado. Se não corresponder, o teste falha.

Para concluir, vamos mostrar o código completo do teste de unidade:

const Stack = require('./stack'); 
describe('Stack', () => {
  let stack;

  beforeEach(() => {
    stack = new Stack();
  });

  test('new stack should be empty', () => {
    // Verifica se a nova pilha está vazia.
    expect(stack.isEmpty()).toBeTruthy();
  });

  test('stack with one element should not be empty', () => {
    // Verifica se a pilha não está vazia após adicionar um elemento.
    stack.push(10);
    expect(stack.isEmpty()).toBeFalsy();
  });

  test('stack should have correct size after pushing elements', () => {
    // Verifica se o tamanho da pilha está correto após adicionar elementos.
    stack.push(10);
    stack.push(20);
    stack.push(30);
    expect(stack.size()).toBe(3);
  });

  test('stack should pop elements in the correct order', () => {
    // Verifica se os elementos são retirados da pilha na ordem correta.
    stack.push(10);
    stack.push(20);
    stack.push(30);
    let result = stack.pop();
    expect(result).toBe(30); // O último elemento empilhado é o primeiro a ser retirado
    result = stack.pop();
    expect(result).toBe(20);
  });

  test('pop should throw an error on empty stack', () => {
    // Verifica se uma exceção é lançada ao retirar um elemento de uma pilha vazia.
    stack.push(10);
    stack.pop(); // Deve funcionar bem
    expect(() => stack.pop()).toThrow('Stack is empty'); // Espera-se um erro aqui
  });

});

Cada função test verifica uma afirmação específica sobre a classe Stack.
A função expect é seguida por uma "matcher function" (toBeTruthy, toBeFalsy, toBe, toThrow), que define o resultado esperado.
A cláusula toThrow é usada para verificar se a função lança um erro quando tentamos fazer pop em uma pilha vazia.

Definições 📚

Mas o que de fato significa essas definições que aparecem quando rodam os testes, como "Test Suites"?

Teste: É como um mini-desafio que o programa precisa passar. No mundo dos testes, é um pedacinho de código que vai verificar se outra parte do programa faz o que deveria fazer.
Fixture: É a preparação, o que você faz antes de começar. Imagine que você precisa que algumas coisas estejam sempre no lugar certo antes de começar um teste. Por exemplo, se você vai testar se um carro anda, você precisa de um carro com motor, rodas e combustível. Isso é o fixture: o conjunto de coisas que você prepara para poder realizar seus testes.
Casos de Teste (Test Case): Isso é como uma coleção de mini-desafios relacionados. É uma classe que tem vários métodos de teste dentro dela. Você pode pensar nela como uma lista de verificações que seu programa precisa passar.
Suíte de Testes (Test Suite): Quando você tem várias coleções de mini-desafios (casos de teste) e quer passar por todas elas de uma vez, isso se chama suíte de testes. É um pacote que junta muitos testes diferentes para rodar todos juntos.
Sistema sob Teste (System Under Test, SUT): É o próprio programa que você está testando. Assim como numa peça de teatro, o "sistema sob teste" é o ator principal, aquele que está sob os holofotes e sendo avaliado para ver se faz tudo certinho. Em outras palavras, é o código real que as pessoas vão usar.

Pensando num exemplo prático: se você tivesse um aplicativo de lista de tarefas, os "testes" seriam os códigos que verificam se você pode adicionar e remover tarefas corretamente, a "fixture" seria a lista inicial que você configura para os testes, os "casos de teste" seriam todas as verificações relacionadas à lista de tarefas, o "suíte de testes" seria um conjunto completo de testes não só da lista de tarefas, mas talvez também de outras partes do aplicativo, e o "SUT" seria o aplicativo de lista de tarefas inteiro que você está testando.

Todas as imagens de explicação de pirâmide de testes foram tiradas do livro eng de software moderna. Disponível em: https://engsoftmoderna.info/cap8.html

Estruturas de projetos baseado em MVC com NodeJS e MongoDB 🏗️

Ágatha — Tue, 17 Oct 2023 19:21:24 +0000

A estrutura de projeto que eu vou descrever não é um padrão de design específico, mas é uma organização comum que se baseia em princípios do padrão de design MVC (Model-View-Controller) em um contexto de desenvolvimento utilizando NodeJS e MongoDB.
Ou seja, é uma estrutura de projeto que segue os princípios do MVC, mas não é necessariamente chamada de MVC em si.

Essa é uma abordagem para deixar o código mais organizado e limpo, separando as responsabilidades em pastas diferentes. Em resumo, é uma estrutura de projeto que é influenciada pelo padrão MVC, mas não é um framework ou implementação formal.

controllers 🎮

A pasta controllers é responsável por guardar os controladores do aplicativo. Os controladores são responsáveis por manipular requisições HTTP, chamar funções dos modelos e retornar as respostas para o cliente. Normalmente cada arquivo nessa pasta vai representar uma entidade ou recurso do aplicativo e contém funções pra lidar com operações relacionadas a ele.

data 📂

A pasta data é responsável por armazenar dados brutos: arquivos JSON, CSV ou scripts que foram gerados no banco de dados. Pode também conter scripts Node.js que são responsáveis por inicializar o banco de dados com dados iniciais. A pasta data é flexível e seu conteúdo pode variar de projeto para projeto, dependendo das necessidades específicas.

models 🏗️

A pasta models contém os modelos do MongoDB, que definem a estrutura dos documentos no banco de dados. Cada arquivo nessa pasta representa um tipo de documento e define os campos, validações e métodos.

public 🌐

A pasta public é usada para armazenar arquivos estáticos, como arquivos CSS, Javascript, imagens e arquivos de mídia. É interessante criar subdiretórios para categorizar os diferentes tipos de recursos, como o CSS para estilização e JS para scripts.

routes 🚦

É onde as definições de rota e controladores associados são mantidas. Gerenciam as solicitações HTTP. Cada rota pode responder a diferentes métodos HTTP, como GET, POST, PUT, DELETE, etc. Geralmente, cada arquivo nessa pasta corresponde a um grupo de rotas relacionadas a um recurso específico.

util 🛠️

Essa pasta pode conter utilitários ou módulos de uso geral que não se encaixam bem em outras categorias. Geralmente possui funções de utilidade, validações e configurações comuns.

views 👁️

A pasta views é onde os arquivos de modelo são armazenados e usados para renderizar a interface do usuário. Esses arquivos geralmente contém código HTML. Geralmente se utiliza um mecanismo de template como EJS, Handlebars, Pug e etc.

Organizando o projeto dessa maneira deixa cada pasta com um papel específico, o que torna a manutenção e colaboração mais eficiente, pois as responsabilidades estão bem definidas. A estrutura exata de um projeto vai variar de acordo com as necessidades do aplicativo e a preferência do time. Entretanto, a organização em camadas e a separação de responsabilidades são princípios importantes a serem seguidos.

Mongoose: entendendo o básico 📖

Ágatha — Thu, 12 Oct 2023 19:52:57 +0000

Mongoose é um biblioteca de Modelagem de Dados de Objeto (ou ODM, do inglês: Object Data Modeling) para MongoDB e Node.js. Ele gerencia o relacionamento entre dados, fornece a validação de esquemas e é usado como tradutor entre objetos no código e a representação desses objetos no MongoDB.

conexão com o banco (MongoDB) 🔌

const mongoose = require("mongoose"); // O primeiro passo é importar o módulo mongoose, ele fornece uma camada de abstração para simplificar a interação com o MongoDB.

mongoose
  .connect(
    "mongodb+srv://hta:agatha@cluster0.r2eb6bu.mongodb.net/shop?retryWrites=true&w=majority"
  ) 
// Esta linha estabelece uma conexão com o banco de dados MongoDB
  .then((result) => {
    app.listen(3006);
  }) 
//  Este bloco é executado quando a conexão com o banco de dados é estabelecida com sucesso. A função app.listen(3006) inicia o servidor da aplicação na porta 3007. 
  .catch((err) => {
    console.log(err);
  }); 
//  Se ocorrer algum erro durante a conexão com o banco de dados, este bloco é executado. O erro é capturado e registrado no console

definir um schema 📄

O esquema define as propriedades do documento através de um objeto, onde o nome da chave corresponde ao nome da propriedade na coleção. Esses são os tipos de esquemas permitidos:

Array
Boolean (ou booleano, em português)
Buffer
Date (ou formato de data, em português)
Mixed (um tipo genérico/flexível de dados)
Number (ou numérico, em português)
ObjectId
String

const mongoose = require('mongoose'); 
// Importa o módulo Mongoose, que é necessário para criar modelos e interagir com bancos de dados MongoDB

const Schema = mongoose.Schema; 
// Armazenamos a classe schema do mongoose na variável 'Schema'

const productSchema = new Schema({ 
//Criamos um novo esquema para representar a estrutura dos documentos que serão armazenados em uma coleção do MOngoDB. O objeto passado para o construtor do Schema define os campos e suas propriedades.
    title: {
        type: String,
        required: true
    },
    price: {
        type: Number,
        required: true
    },
    description: {
        type: String,
        required: true
    }
});

Portanto, o productSchema descreve a estrutura dos documentos que representam produtos. Cada documento precisa ter um título, preço e descrição, e esses campos devem conter os tipos de dados especificados.
Agora, o productSchema pode ser usado para criar modelos de dados que se encaixam nesse esquema. Esses modelos são usados para interagir com a coleção no banco de dados MongoDB e realizar operações como criar, ler, atualizar e excluir documentos.

exportar um modelo 📦

module.exports = mongoose.model('Product', productSchema);

Para exportar um modelo no mongoose, você define um nome para ele e indica o nome da entidade.
Essa linha de código combina o esquema productSchema com o nome 'Product' para criar um modelo que representa documentos com a estrutura definida no esquema.
Esse modelo pode ser usado para e*xecutar operações no banco de dados*, como criar, ler, atualizar e excluir documentos na coleção 'Product'.
Após essa exportação, o modelo 'Product' estará disponível para uso em outros arquivos e partes do seu aplicativo Node.js.

buscando um produto 🔍

exports.getProducts = (req, res, next) => {
  Product.find()
    .then((products) => {
      res.render("shop/product-list", {
        prods: products,
        pageTitle: "All Products",
        path: "/products",
      });
    })
    .catch((err) => {
      console.log(err);
    });
};

O método find() do Mongoose é uma das operações mais comuns e fundamentais para recuperar documentos de um banco de dados MongoDB. Ele é usado para consultar documentos em uma coleção com base em critérios de pesquisa e retorna um ou mais documentos que correspondem a esses critérios. Essa chamada procura todos os documentos no banco de dados MongoDB associados ao modelo Product.

atualizando um produto 🔄

exports.postEditProduct = (req, res, next) => {
  const prodId = req.body.productId; //  Obtém o ID do produto a ser editado do corpo da solicitação
  const updatedTitle = req.body.title;
  const updatedPrice = req.body.price;
  const updatedImageUrl = req.body.imageUrl;
  const updatedDesc = req.body.description;

  Product.findById(prodId) // Esta linha faz uma consulta ao banco de dados para localizar o produto com o ID especificado (prodId) usando o método findById() do modelo Product. Isso é feito para recuperar o produto existente que será atualizado.
    .then((product) => { // Se o produto for encontrado com sucesso, a função dentro deste bloco .then() será executada. Ela recebe o produto encontrado como argumento (representado pela variável product).
      product.title = updatedTitle;
      product.price = updatedPrice;
      product.description = updatedDesc;
      product.imageUrl = updatedImageUrl;
      return product.save(); // Após a atualização das propriedades do produto, a função .save() é chamada para salvar essas alterações no banco de dados.
    })
    .then((result) => {
      console.log("UPDATED PRODUCT!");
      res.redirect("/admin/products");
    })
    .catch((err) => console.log(err)); // Se houver algum erro durante o processo de atualização ou salvamento do produto, o erro será capturado neste bloco .catch() e registrado no console.
};

Esse controlador é responsável por a*tualizar as informações de um produto* no banco de dados com base nos dados enviados por um formulário de edição. Ele primeiro localiza o produto pelo ID, atualiza suas propriedades e, em seguida, salva as alterações no banco de dados. Se bem-sucedido, a resposta é redirecionada para a página de administração de produtos; caso contrário, qualquer erro é registrado no console.

deletando um produto 🗑️

exports.postDeleteProduct = (req, res, next) => {
  const prodId = req.body.productId; //Obtém o ID do produto que deve ser excluído a partir do corpo da solicitação POST.
  Product.findByIdAndRemove(prodId) // Esta linha realiza a exclusão do produto com o ID fornecido (prodId) no banco de dados MongoDB. Ela utiliza o método findByIdAndRemove do modelo Mongoose Product para localizar e remover o documento correspondente no banco de dados com base no ID.
    .then(() => {
      console.log("DESTROYED PRODUCT");
      res.redirect("/admin/products");
    }) // Se a exclusão do produto for bem-sucedida, o código dentro deste bloco .then() é executado. Neste caso, ele imprime "DESTROYED PRODUCT" no console e, em seguida, redireciona o usuário para a página "/admin/products".
    .catch((err) => console.log(err)); //Se ocorrer algum erro durante o processo de exclusão do produto, o erro é capturado neste bloco .catch() e é registrado no console.
};

Esta função controladora é usada para excluir um produto do banco de dados com base no ID do produto fornecido na solicitação POST. Se a exclusão for bem-sucedida, uma mensagem é registrada no console e o usuário é redirecionado para a página de administração de produtos. Se houver algum erro durante o processo de exclusão, o erro é registrado no console.

relacionando schemas 🧩

const Schema = mongoose.Schema;

const productSchema = new Schema({
    userId: {
        type: Schema.Types.ObjectId,
        ref: "User", // estabelece uma referencia ao uma diferente coleção chamada User
        required: true
    }
});

module.exports = mongoose.model('Product', productSchema);

O productSchema inclui um campo chamado userId, que é um tipo Schema.Types.ObjectId e faz referência à coleção 'User'. Isso significa que o valor desse campo será o ID de um documento na coleção 'User'.

const Schema = mongoose.Schema;

const userSchema = new Schema({
  cart: {
    items: [
      {
        productId: {
          type: Schema.Types.ObjectId,
          ref: "Product",
          required: true,
        },
        quantity: { type: Number, required: true },
      },
    ],
  },
});
module.exports = mongoose.model("User", userSchema);

Cada item do carrinho é representado por um objeto que inclui o productId (que é uma referência à coleção 'Product') e a quantity (a quantidade do produto no carrinho).
Isso permite que um usuário tenha produtos em seu carrinho e que esses produtos sejam referências a documentos da coleção 'Product'. A relação entre os usuários e os produtos é estabelecida por meio do campo productId.