Skip to content

033. Nome padrão de uma feature helpers de teste

Filipe Deschamps edited this page Feb 22, 2022 · 1 revision

11/02/2022

Nome das features

Este PR inverte o nome das features de action:object:extras para object:action:extras

Então ao invés de update:user, agora fica user:update, porém não sei. O @tccarreira fez uma issue SENSACIONAL que centralizou uma pesquisa no assunto e trouxe vários pontos de vista diferentes. Não cheguei a uma conclusão de qual padrão usar, mas estou pensando em voltar como era antes para facilitar a leitura em onde a feature é usada e casar melhor com o seu modificador extra, por exemplo: read:user:email.

Linting e versão do Node

O @jsfelix neste PR fixou a versão do Node.js para quem usa NVM e também fez os warning do linting quebrar no CI, o que é ótimo.

Instruções no README

Também adicionamos por esse PR instruções de como instalar, rodar e testar o projeto.

Mais helpers para facilitar os testes

Uma coisa muito importante que esse PR adiciona, são os helpers para criar, ativar, setar ou remover features e criar sessões de usuários, sem precisar passar pelo fluxo dos endpoints. Isso facilita você separar o que é boilerplate para chegar no state desejado de o que você realmente quer testar.

Usando o PR anterior como exemplo, eu queria testar se um usuário conseguia atualizar as informações de outro usuário. Então o foco aqui não é criar contas, fazer elas passarem pelo fluxo de ativação por email, nem criar uma sessão ativa... o foco era simplesmente um usuário válido dando PATCH em outro usuário.

Então o boilerplate para chegar no state correto dos usuários foi esse:

    let firstUser;
    let firstUserSession;
    let secondUser;

    beforeEach(async () => {
      firstUser = await orchestrator.createUser();
      firstUser = await orchestrator.activateUser(firstUser);
      firstUserSession = await orchestrator.createSession(firstUser);
      secondUser = await orchestrator.createUser();
    });

Novamente, eu não quero testar essa parte, pois o que eu quero realmente testar e criar expectativas a respeito é nessa parte (que é usar a sessão do primeiro usuário, para alterar os dados do segundo usuário):

    test('Patching other user username', async () => {
      const response = await fetch(`${orchestrator.webserverUrl}/api/v1/users/${secondUser.username}`, {
        method: 'patch',
        headers: {
          'Content-Type': 'application/json',
          cookie: `session_id=${firstUserSession.token}`,
        },

        body: JSON.stringify({
          username: 'updateOthersPatchingOtherUser',
        }),
      });