• Cada grupo terá uma branch específica no formato main-group-X. Ex: main-group-1; main-group-2; etc;

• Para entregar o seu projeto você deverá criar um Pull Request base neste repositório no formato [MAIN GROUP X] [BASE]. Seu Pull Request deve apontar da branch main-group-X para a branch main (que será sua PR principal) e deve agregar todo o trabalho do seu grupo para avaliação no final do desenvolvimento;

• Cada feature/fix/etc deve ser desenvolvida em uma nova branch, cujo formato preferencialmente deve ser main-group-X-<alteração>-<especificação>. Ex: main-group-1-feat-login-form. Isso ajudará tanto o seu time quanto a equipe de instrução a localizar seus trabalhos no projeto;

• No término do projeto, cada feature/fix/etc deve ser mergeada (preferencialmente via PR, com code review e aprovação de todo o grupo) com a branch principal do grupo, onde ocorrerá a avaliação. Ex: main-group-1-feat-login-form deve ser mergeado com main-group-1;

• Cada PR deve, preferencialmente, ter o título no formato [MAIN GROUP X] [CONTEXTO] [ALTERAÇÃO] [DESCRIÇÃO]. Ex: [MAIN GROUP 1] [API] [FEAT] [LOGIN]; [MAIN GROUP 1] [FRONT] [FEAT] [LOGIN-FORM]; etc. Isso ajudará tanto o seu time quanto a equipe de instrução a localizar seus trabalhos no projeto.

Lembre-se que você pode consultar nosso conteúdo sobre Git & GitHub e nosso Blog - Git & GitHub sempre que precisar!

Esse será o seu projeto mais completo até agora! Nessa aplicação, seu grupo será responsável por criar e integrar tanto o back-end quanto o front-end, criando uma plataforma de delivery de cerveja. 🍻

O projeto não é só codar, mas também é trabalhar em equipe, aprender e se divertir muito!

Neste projeto, seu grupo deve desenvolver um app de delivery para uma distribuidora de bebidas. Veja abaixo o contexto da entrega que deve ser feita:

A distribuidora de cervejas da dona Tereza está se informatizando! 🚀 Seu negócio, antes focado em um local específico da cidade, passou a receber uma quantidade massiva de encomendas de outros pontos, expandindo sua atuação via delivery. Isso tudo graças ao excelente preço das bebidas e atendimento da equipe de vendas.

Agora a distribuidora possui alguns pontos de venda na cidade para agilizar no atendimento dessas áreas. Cada ponto de venda, por sua vez, possui uma pessoa vendedora responsável.

Como seu antigo sistema, que era um conjunto de planilhas, já não atende a necessidade do negócio por gerar muita manutenção, dona Tereza procurou a sua equipe de pessoas desenvolvedoras com uma ideia de aplicativo que pudesse agilizar a vida de sua equipe e das pessoas que compram seus produtos. O aplicativo precisa:

• Ter acesso via login: tanto clientes como pessoas vendedoras, assim como a própria dona Tereza, que administra o sistema, devem ter acesso ao aplicativo via login, porém para funções diferentes: (1) A pessoa cliente, que compra da lista de produtos; (2) A pessoa vendedora, que aprova, prepara e entrega; (3) A pessoa administradora, que gerencia quem usa o aplicativo;
• Fazer a comunicação entre clientes e pessoas vendedoras: a pessoa cliente faz o pedido via "carrinho de compras" e a pessoa vendedora aprova, prepara e envia esse pedido. Quando o produto é recebido por quem comprou, essa pessoa marca o pedido como "recebido". Ambos devem possuir detalhes sobre seus pedidos;
• Se a pessoa cliente faz o pedido, o mesmo deve aparecer para a pessoa vendedora em seu dash de pedidos após a atualização da página. A pessoa cliente, por sua vez, deve ter as informações sobre seu pedido quando sua página for atualizada, ou seja, ter informações se o pedido está sendo preparado ou se já saiu pra entrega;

Sua equipe, que já possui uma boa experiência com desenvolvimento, em pouco tempo apresentou um protótipo e um Diagrama de ER conforme imagem:

A ideia da sua equipe já pressupõe alguma escalabilidade, dado que foram estabelecidas algumas entidades genéricas no banco de dados e componentização no front-end, para que, caso o sistema cresça, não seja muito difícil mudar e ampliar essa estrutura.

A proposta encantou, mas dona Tereza quer ver o negócio em ação! Ela está disposta a pagar por um MVP do projeto e vocês fecharam o negócio com um prazo combinado para entrega.

Agora é mãos à obra! Vamos começar?

• Este projeto é em grupo;
• Serão 12 dias de projeto;
• Data de entrega para avaliação final do projeto: 23/11/2022 14:00.

1. Clone o repositório

• Use o comando: git clone [email protected]:tryber/sd-020-b-project-delivery-app.git.
• Entre na pasta do repositório que você acabou de clonar:
  • cd sd-020-b-project-delivery-app
• Vá para a branch do seu grupo, com git checkout main-group-XX && git pull, onde XX é o número do seu grupo. Exemplos: main-group-1, main-group-22.

2. Instale as dependências

• Para isso, use o seguinte comando: npm install

3. Faça alterações separadas por novas branchs, criadas a partir da branch main-group-XX. Lembre-se de criar uma nova branch para cada demanda.

• Verifique se você está na branch main-group-XX
  • Exemplo: git branch
• Se não estiver, mude para a branch main-group-XX
  • Exemplo: git checkout main-group-XX && git pull
• Agora, crie uma branch para a demanda que você vai desenvolver do seu projeto
  • Você deve criar uma branch com uma breve descrição da demanda a ser desenvolvida
  • Exemplo: git checkout -b main-group-XX-cria-campo-de-input

4. Adicione as mudanças ao stage do Git e faça um commit

• Verifique se as mudanças ainda não estão no stage
  • Exemplo: git status (devem aparecer listadas as novas alterações em vermelho)
• Adicione o novo arquivo ao stage do Git
  • Exemplo:
    • git add . (adicionando todas as mudanças - que estavam em vermelho - ao stage do Git)
    • git status (deve aparecer listado o arquivo joaozinho/README.md em verde)
• Faça o commit inicial
  • Exemplo:
    • git commit -m 'iniciando o projeto x' (fazendo o primeiro commit)
    • git status (deve aparecer uma mensagem tipo nothing to commit )

5. Adicione a sua branch com o novo commit ao repositório remoto

• Usando o exemplo anterior: git push -u origin main-group-XX-cria-campo-de-input

6. Crie um novo Pull Request (PR)

• Vá até a página de Pull Requests do repositório no GitHub
• Clique no botão verde "New pull request"
• Clique na caixa de seleção "Compare" e escolha a branch do grupo, main-group-XX, e a sua branch com atenção
• Coloque um título para a sua Pull Request
  • Exemplo: "[GRUPO XX] Cria tela de busca"
• Clique no botão verde "Create pull request"
• Adicione uma descrição para o Pull Request e clique no botão verde "Create pull request"
• Não se preocupe em preencher mais nada por enquanto!
• Volte até a página de Pull Requests do repositório e confira que o seu Pull Request está criado

7. Assim que aprovado por pelo menos duas pessoas do seu grupo e com o Linter adereçado, acesse SEU Pull Request e clique no botão "Merge pull request"

• Faça commits das alterações que você realizar no código regularmente;

• Lembre-se de sempre após um (ou alguns) commits atualizar o repositório remoto;

• Os comandos que você utilizará com mais frequência são:

  1. git status (para verificar o que está em vermelho - fora do stage - e o que está em verde - no stage)
  2. git add (para adicionar arquivos ao stage do Git)
  3. git commit (para criar um commit com os arquivos que estão no stage do Git)
  4. git push -u origin nome-da-branch (para enviar o commit para o repositório remoto na primeira vez que fizer o push de uma nova branch)
  5. git push (para enviar o commit para o repositório remoto após o passo anterior)

Para sinalizar que o seu projeto está pronto para "Code Review", faça o seguinte:

• Vá até a página DO SEU Pull Request, adicione a label de "code-review" e marque seus colegas:

  • No menu à direita, clique no link "Labels" e escolha a label code-review;

  • No menu à direita, clique no link "Assignees" e escolha o seu usuário;

  • No menu à direita, clique no link "Reviewers" e digite students, selecione o time tryber/students-sd-020-b.

Caso tenha alguma dúvida, aqui tem um video explicativo.

Use o conteúdo sobre Code Review para te ajudar a revisar os Pull Requests.

São os scripts da raiz do projeto (./package.json) e não das aplicações individuais ./front-end/package.json e ./back-end/package.json:

• start: Limpa as portas 3000 e 3001 e simula a inicialização no avaliador. Também prepara o campo rodando o Sequelize para restaurar o banco de dados de testes (final -test) e sobe a aplicação com pm2 em modo fork (uma instância para cada aplicação). Nesse modo, as alterações não são assistidas;

  • uso (na raiz do projeto): npm start

• stop: Para e deleta as aplicações rodando no pm2;

  • uso (na raiz do projeto): npm stop

• dev: Limpa as portas 3000 e 3001 e sobe a aplicação com pm2 em modo fork (uma instância pra cada aplicação). Nesse modo, as atualizações são assistidas (modo watch);

  • uso (na raiz do projeto): npm run dev

• dev:prestart: A partir da raiz, esse comando faz o processo de instalação de dependências (npm i) nos dois projetos (./front-end e ./back-end) e roda o Sequelize no ./back-end (lembrar de configurar o .env no mesmo);

  • uso (na raiz do projeto): npm run dev:prestart

• db:reset: Roda os scripts do Sequelize restaurando o banco de dados de desenvolvimento (final -dev). Utilize esse script caso ocorra algum problema no seu banco local;

  • uso (na raiz do projeto): npm run db:reset

• db:reset:debug: Roda os scripts do Sequelize restaurando o banco de dados de desenvolvimento (final -dev). Utilize esse script caso ocorra algum problema no seu banco local. Esse comando também é capaz de retornar informações detalhadas de erros (quando ocorrerem no processo);

  • uso (na raiz do projeto): npm run db:reset:debug

• test <nomes-dos-arquivos>: Roda todos os testes (ou uma parte deles caso <nomes-dos-arquivos> seja definido) utilizando o banco de dados de testes (final -test);

  • uso (na raiz do projeto): npm test, npm test 01login 02register ou ainda npm run test 01 02

• test:dev <nomes-dos-arquivos>: Roda todos os testes (ou uma parte deles caso <nomes-dos-arquivos> seja definido) utilizando o banco de dados de desenvolvimento (final -dev);

  • uso (na raiz do projeto): npm run test:dev, npm run test:dev 01login 02register ou ainda npm test:dev 01 02;

• test:dev:open <nomes-dos-arquivos>: Roda todos os testes (ou uma parte deles caso <nomes-dos-arquivos> seja definido) utilizando o banco de dados de desenvolvimento (final -dev), exemplo npm test:dev:open 01login 02register ou ainda npm test:dev:open 01 02. Esse teste deve abrir uma janela mostrando o comportamento das páginas;

  • uso (na raiz do projeto): npm run test:dev:open, npm run test:dev:open 01login 02register ou ainda npm test:dev:open 01 02;

• test:dev:report "<nomes-dos-arquivos>": Roda todos os testes (ou uma parte deles caso "<nomes-dos-arquivos>" seja definido) utilizando o banco de dados de desenvolvimento (final -dev). Esse teste devolve um output em texto com o resultado de todos os testes. Os logs são gerados em ./__tests__/reports.

  • uso (na raiz do projeto): npm run test:dev:report, npm run test:dev:report "01login 02register" ou ainda npm run test:dev:report "01 02";

Para fazer a análise estática do seu código neste projeto, vamos utilizar o linter ESLint. Assim o código estará alinhado com as boas práticas de desenvolvimento, sendo mais legível e de fácil manutenção!

➡️ Este projeto já vem com as dependências relacionadas ao linter configuradas nos arquivos package.json nos seguintes caminhos: - sd-020-b-project-delivery-app/back-end/package.json - sd-020-b-project-delivery-app/front-end/package.json

➡️ Para poder rodar o ESLint basta:

• Executar o comando npm install dentro do projeto, de forma individual, ou seja, execute esse comando dentro da pasta back-end e também na pasta front-end;

• Depois execute o comando npm run lint dentro de cada uma dessas pastas, assim você verifica as particularidades individualmente;

• Se a análise do ESLint encontrar problemas no seu código, eles serão mostrados no seu terminal.

• Se não houver problema no seu código, nada será impresso no seu terminal.

• Você pode também instalar o plugin do ESLint no VSCode. Para isso, bastar ir em extensions e baixar o plugin ESLint.

👀 De olho na dica: abra separadamente cada pasta do projeto (back-end e front-end em VSCodes separados, para tirar proveito do ESLint individual de cada projeto).

⚠️ Importante: Devido ao fato de as configurações das regras do ESLint dos projetos de front e back serem diferentes, é preciso executar o ESLint em cada projeto.

➡️ Usaremos também o StyleLint para fazer a análise estática do seu código, especialmente em Front-end.

➡️ Para poder rodar o StyleLint em um projeto basta:

• Executar o comando npm install dentro do projeto de front-end;

• Depois execute o comando npm run lint:styles;

• Se a análise do StyleLint encontrar problemas no seu código, tais problemas serão mostrados no seu terminal;

• Se não houver problema no seu código, nada será impresso no seu terminal.

➡️ Caso ainda fique alguma dúvida, você pode consultar nosso conteúdo sobre ESLint

⚠️ Importante: o Stylelint é aplicável apenas no front-end.

⚠️ Importante: Pull Requests com issues de Linter não serão avaliadas. Atente-se para resolvê-las antes de finalizar o desenvolvimento.

⚠️ Atenção: O avaliador automático não necessariamente avalia seu projeto na ordem em que os requisitos aparecem no readme. Isso acontece para deixar o processo de avaliação mais rápido. Então, não se assuste se isso acontecer, ok?

Para o banco de dados, utilizaremos o ORM Sequelize, que fará interface com o MySQL. Para isso, atente-se às seguintes orientações:

• Utilize para referência de criação de migrations e seeders o arquivo ./db.example.sql;
• O Diagrama de ER também pode ajudar a "visualizar" o banco de dados;
• Respeite a estrutura do banco de dados, ou seja, sua implementação não deve adicionar ou remover tabelas, campos ou relacionamentos e sua API deve estar preparada para aproveitar essa estrutura por completo.

⚠️ A configuração do sequelize pode ser considerado o requisito zero do projeto, dado que a maior parte dos testes dependem da estrutura de alguma tabela para realização de testes, portanto, deve ser feita primeiro.

⚠️ Antes de iniciar o projeto, garanta que o Sequelize roda corretamente no ./back-end (pela raiz do projeto, o comando npm run db:reset será de grande ajuda, pois serve para restaurar o banco de dados -dev). O avaliador vai executar funções do sequelize para garantir a estrutura do banco de dados.

O projeto já provê uma estrutura inicializada do ORM (em ./back-end/src/database). Aqui, é necessário que você desenvolva as migrations e seeders corretamente, seguindo o modelo em ./db.example.sql (esse arquivo serve como referência, e não tem qualquer influência sobre a aplicação ou avaliação).

⚠️ O avaliador usará valores default no arquivo ./back-end/src/database/config/config.js, que já vem no projeto caso nada seja definido. Portanto, tome cuidado na hora de fazer qualquer alteração nesse arquivo, pois é através dele que o avaliador utilizará as referências do banco de dados correto para cada situação (desenvolvimento e testes).

• Esse projeto fornece por padrão o arquivo .sequelizerc em .back-end para configurações do padrão de pastas no Sequelize.

• Opcionalmente no desenvolvimento local, você pode alterar o valor EVAL_ALWAYS_RESTORE_DEV_DB do arquivo .env em ./back-end para false, o que persistirá os dados dos testes locais durante os mesmos. Essa opção pode gerar implicações para a performance e confiabilidade do teste local, já que o avaliador pode se comportar mal caso haja uma quantidade grande de registros para avaliar. Caso ocorra algum problema, utilize o comando npm run db:reset ou npm run db:reset:debug (para encontrar erros) pela raiz do projeto para restaurar o banco, ou altere de volta a opção EVAL_ALWAYS_RESTORE_DEV_DB para true.

• ⚠️ O projeto só instala as dependências com a versão 16 do node para evitar conflitos de versão, caso não tenha essa versão instalada você pode usar o nvm para fazer o gerenciamento de versões.

• ⚠️ O processo de avaliação completo é bem demorado (em torno de 20 minutos), por isso, é importante que os testes sejam feitos por partes, localmente, antes de serem enviados para o avaliador!. Para isso, utilize os comandos de teste local (npm run test:dev*) apresentados em scripts relevantes do package.json principal!

  ▶️ Exemplo: Após terminar os requisitos do primeiro arquivo (01login.test.js), você pode utilizar o comando npm run test:dev 01 ou npm run test:dev:open 01(caso queira visualizar) para testar aquela parte do projeto.

  ▶️ Aqui, vocês também tem liberdade para utilizar os comandos .only ou .skip para validar testes específicos no avaliador local (pasta ./__tests__/end-to-end), exemplo:

/*
  
 - ⚠️ **IMPORTANTE**: esse artifício **não deve ser "commitado" com o projeto, sob risco de desqualificação na avaliação**, porém pode ser utilizado para ganhar tempo no teste local.
*/

describe(requirement(1), () => {
  test.only("O avaliador navegará para o endereço do host utilizando o endpoint '/'", async () => { // O `test.only` deve rodar o teste específico do requisito 1 e pular os demais
    // ...
  });
});

• ⚠️ Para testes locais, é fundamental configurar o arquivo de variáveis de ambiente .env (de environment) dentro da pasta ./back-end (ele é o único .env no projeto), conforme exemplo em .env.example, na mesma pasta. Esse arquivo servirá de referência para o avaliador e caso não exista, o avaliador vai utilizar valores default para o processo (O que pode estourar erro no teste local, caso suas configurações não sejam as mesmas).

• ⚠️ Excepcionalmente nesse projeto, existe a necessidade de manter e subir para o repositório o arquivo jwt.evaluation.key, que também deve estar em ./back-end. Esse arquivo deve conter única e exclusivamente a chave utilizada para criptografia com JWT, que também vai ser testado pelo avaliador. Nesse sentido, esse arquivo pode ser lido por sua aplicação na hora de trabalhar com tokens.

• ⚠️ Inicie o projeto pela raiz, utilizando o comando npm i. Após isso, é possível fazer a instalação de ambos os aplicativos (back e front) através da raiz do projeto, utilizando o comando npm run dev:prestart (esse comando também restaurará o banco de dados, caso o .env esteja configurado corretamente).

O data-testid de cada elemento que será usado na avaliação do projeto está no arquivo data-testids.txt na raiz do projeto. Cada um desse elementos tem no protótipo do figma um número, e nesse arquivo, o data-testid que deve ser atribuído ao valor de tal.

👀 De olho na dica: você pode ler mais sobre os atributos data-* neste link.

Para facilitar o entendimento, podemos dividir a aplicação em 4 fluxos principais, uma validação de status entre cliente e pessoa vendedora e cobertura de testes (front-end e back-end):

• Fluxo Comum que compreende:

  • (1) Tela de Login (01login.test);
  • (2) Tela de Registro (02register.test).

• Fluxo do Cliente que compreende: :

  • (3) Tela de Produtos (03customer_products.test);
  • (4) Tela de Checkout (04customer_checkout.test);
  • (5) Tela de Pedidos (05customer_orders.test);
  • (6) Tela de Detalhes do Pedido (06customer_order_details.test).

• Fluxo da Pessoa Vendedora que compreende:

  • (7) Tela de Pedidos (07seller_orders.test);
  • (8) Tela de Detalhes/Controle do Pedido (08seller_order_details.test).

• Validação do Status do Pedido que compreende:

  • (9) Teste de status (09customer_seller_status_sync.test);

• Fluxo da Pessoa Administradora que compreende:

  • (10) Tela de gerenciamento de usuários (11admin_manage_users.test).

• Testes da aplicação que compreende:

  • (11) Testes de cobertura (12coverage_tests.test).

• ⚠️ Importante ⚠️: a tela de login deve ser capaz de direcionar para a tela principal de cada pessoa usuária, sendo as páginas:

  • Do cliente: /customer/products,
  • Da pessoa vendedora: /seller/orders,
  • Da pessoa administradora: /admin/manage

• Utilize esse protótipo para se guiar na construção do front-end. Esse arquivo é comentado com os nomes de cada elemento.

⚠️Importante: é necessário ter feito login no figma para visualizar o protótipo. Para ver os comentários sobre cada componente, basta clicar no ícone de comentários no Figma (lado esquerdo superior), conforme a imagem abaixo:

• Para servir arquivos estáticos como imagens no back-end, utilize o seguinte path:./back-end/public;
• ⚠️Importante: nosso banco de imagens pode ser baixado aqui;

O nosso protótipo possui um conjunto de componentes base. Isso é proposital e sugere que é fundamental que vocês componentizem o front-end de maneira que seja possível fazer o maior reaproveitamento possível de cada estrutura.

É bom lembrar que um front-end em React com pouca componentização gera muita manutenção no tempo e atrasa a entrega. Aqui, é aconselhável pensar utilizando um modelo atômico de desenvolvimento.

• Escreva testes unitários e sinta-se livre para alterar a UI. Contudo, respeite os atributos data-testid, pois eles serão usados na correção do projeto.

• Caso necessite realizar upload de algum arquivo/imagem, pode utilizar a ferramenta/tecnologia de sua preferência, ressaltamos aqui:
  • Express Static, uma ferramenta simples e prática, já integrada ao express para servir arquivos estáticos.
  • Multer, uma ferramenta mais completa sobre a qual temos um conteúdo na parte de Real Life Engineer.

Ao finalizar e submeter o projeto, não se esqueça de avaliar sua experiência preenchendo o formulário. Leva menos de 3 minutos!

Link: Formulário de avaliação do projeto

Você sabia que o LinkedIn é a principal rede social profissional e compartilhar o seu aprendizado lá é muito importante para quem deseja construir uma carreira de sucesso? Compartilhe esse projeto no seu LinkedIn, marque o perfil da Trybe (@trybe) e mostre para a sua rede toda a sua evolução.

• O avaliador navegará para o endereço do host utilizando o endpoint /;
  • O avaliador verificará o redirecionamento para página /login;
• O avaliador navegará para o endereço do host utilizando o endpoint /login.

• O avaliador buscará pelos elementos fundamentais aos demais testes.

• O avaliador testará 3 situações aleatórias diferentes (uma para cada validação) de maneira isolada, sendo uma delas válida;
• O avaliador testará seu formulário com as 3 situações de maneira sequencial;
• O avaliador não vai executar o login pelo botão de login, ele validará se o botão ficará habilitado ou não, a depender dos critérios durante o input dos dados;
• É esperado que haja a validação dos dados durante a escrita dos mesmos.

• O avaliador tentará fazer login através do botão de login, com dados aleatórios válidos;
• O avaliador espera que haja uma requisição POST para API, que retorne o status 404 - Not found;
• O avaliador deve identificar que o endereço da página não foi alterado;
• O avaliador espera que apareça na tela um elemento, antes oculto, com uma mensagem de erro qualquer.
  • Elemento: common_login__element-invalid-email

• O avaliador tentará fazer a ação de login com dados válidos. Esse teste pressupõe a validade de anteriores;
  • O avaliador utilizará o e-mail [email protected] e senha $#zebirita#$ para fazer o login;

• O avaliador navegará para o endereço do host utilizando o endpoint /register;
• O avaliador tentará, pela tela de login, acessar a página de registro clicando no Botão de cadastro.

• O avaliador buscará pelos elementos fundamentais aos demais testes.

• O avaliador testará 4 situações aleatórias diferentes (uma para cada validação) de maneira isolada, sendo uma delas válida;
• O avaliador testará seu formulário com as 4 situações de maneira sequencial;
• O avaliador não vai executar o registro pelo botão de registro. Ele validará se o botão ficará habilitado ou não, a depender dos critérios durante o input dos dados;
• É esperado que haja a validação dos dados durante a escrita dos mesmos.

• O avaliador tentará fazer a ação de cadastro com dados aleatórios válidos, validando-os posteriormente no banco de dados;
• O avaliador espera que haja uma requisição POST para API ao clicar no Botão de registro, que retorne o status 201 - Created;
• O avaliador espera acessar uma página localhost:3000/customer/products como padrão para o usuário do tipo cliente;
• Não é necessário ter a página pronta, mas a rota no front deve estar acessível para que o avaliador a identifique.

• O avaliador tentará realizar o fluxo de cadastro anterior duas vezes, com um dado gerado aleatoriamente.
• Na primeira vez o avaliador espera que haja uma requisição POST para API ao clicar no Botão de registro, que retorne o status 201 - Created;
• Na segunda vez o avaliador espera que haja uma requisição POST para API ao clicar no Botão de registro, que retorne o status 409 - Conflict;
• O avaliador espera que apareça na tela um elemento, antes oculto, com uma mensagem de erro qualquer.
  • Elemento: common_register__element-invalid_register;

O avaliador buscará pelos elementos fundamentais aos demais testes:

• Elemento genérico que seja um item de menu para página de produtos;
• Elemento genérico que seja um item de menu para página de pedidos;
• Elemento genérico para o nome da pessoa usuária;
• Elemento genérico que seja um item de menu para o logout.

O avaliador buscará pelos elementos relacionados a todos os cards de produtos:

• Elemento genérico do nome/título do produto;
• Elemento genérico do preço do produto;
• Imagem do produto;
• Botão para adicionar quantidade de itens;
• Botão para remover quantidade de itens;
• Input de quantidade de itens.

• O avaliador testará se o local storage contém os dados da pessoa usuária após o login;
• O avaliador testará se o nome da pessoa, contido no local storage, também está na navbar;
• O avaliador testará se o local storage contém um token válido;
• O avaliador testará se o logout descarta os dados do local storage da pessoa usuária.

• O avaliador testará se os dados de cada card condizem com os dados do banco de dados.
• O avaliador testará se é possível fazer uma requisição para os endereços das imagens de cada produto.

• O avaliador vai utilizar um recorte aleatório de produtos para fazer o pedido (esses dados são imprimidos durante o teste);
• Para cada item da lista gerada:
  • O avaliador testará se a adição do item (Botão de adição) adiciona ao input da quantidade;
  • O avaliador testará se após a adição do item, a ação de remoção (Botão de remoção) do dobro da quantidade manterá o input da quantidade em 0 (não gerando valores negativos);
  • O avaliador testará se é possível fazer a alteração manual input da quantidade;
  • O avaliador testará o fluxo completo de adição de itens, validando o valor total de produtos.

• O avaliador testará a existência de um botão de carrinho com um valor total válido e que seja capaz de nos direcionar à tela de checkout.
  • O avaliador espera acessar uma página localhost:3000/customer/checkout após o clique no botão do carrinho;
  • Não é necessário ter a página pronta, mas a rota no front deve estar acessível para que o avaliador a identifique.

• O avaliador testará os data-testids referentes aos itens do carrinho e demais elementos.

• O avaliador testará se os itens contidos na venda correspondem aos itens do checkout

• O avaliador tentará realizar a remoção de itens validando-os na tabela.
  • O avaliador vai deletar uma quantidade aleatória de itens do carrinho (esses dados são impressos no teste).

• O avaliador verificará se ao final do checkout é disparado uma request POST com uma autorização (token) válida, que retorne status 201 - Created;
• O avaliador verificará se após isso o endereço da url contém o id do pedido criado. Por exemplo, se o id gerado for 3, então: localhost:3000/customer/orders/3.

• O avaliador testará se, após realizado o checkout, as alterações constarão no banco de dados.

• O avaliador vai testar se existem data-testids para os dez primeiros itens contidos na tabela 'sales'; ⚠️Importante: o avaliador oficial vai testar somente uma venda, mas caso você opte por usar o parâmetro de ambiente EVAL_ALWAYS_RESTORE_DEV_DB=false no back-end, localmente o teste fará avaliação de até dez vendas.

• O avaliador vai testar se os dados associados aos data-testids dos dez primeiros itens coincidem com os do banco de dados. ⚠️Importante: o avaliador oficial vai testar somente uma venda, mas caso você opte por usar o parâmetro de ambiente EVAL_ALWAYS_RESTORE_DEV_DB=false no back-end, localmente o teste fará avaliação de até dez vendas.

• O avaliador acessará a tela de detalhes do último pedido pela tela de pedidos, após o checkout do mesmo. Por exemplo:
  • Se o pedido gerado for o de id 5, o avaliador espera acessar o endereço localhost:3000/customer/orders/5 via aquele card,

• O avaliador testará os data-testids referentes aos itens da venda e demais elementos.

• O avaliador testará se os dados contidos nos campos das linhas (produtos relacionados à venda), tal como demais valores (id do pedido, nome da pessoa vendedora, data de pedido, status da venda, preço total) conferem com os dados da venda feita anteriormente.

• O avaliador vai testar se existem data-testids para os dez primeiros itens contidos na tabela 'sales'.

• O avaliador vai testar se os dados associados aos data-testids dos dez primeiros itens batem com os do banco de dados.

• O avaliador acessará a tela de detalhes do último pedido pela tela de pedidos, após o checkout do mesmo. Por exemplo:
  • Se o pedido gerado for o de id 5, o avaliador espera acessar o endereço localhost:3000/seller/orders/5, via aquele card.

• O avaliador testará os data-testids referentes aos itens da venda e demais elementos.

• O avaliador testará se os dados contidos nos campos das linhas (produtos relacionados à venda), tal como demais valores (id do pedido, nome da pessoa vendedora, data de pedido, status da venda, preço total) conferem com os dados da venda feita anteriormente.

• O avaliador testará se a alteração do pedido é persistente após atualizar a página fazendo o processo de logout/login.

• O avaliador verificará se, ao alterar o status do pedido na tela da pessoa vendedora, o mesmo também é alterado na tela de detalhes do pedido do cliente após atualização das páginas fazendo o processo de logout/login nas mesmas.

• O avaliador verificará se, ao alterar o status do pedido na tela da pessoa vendedora, o mesmo também é alterado na tela de pedidos do cliente após atualização das páginas fazendo o processo de logout/login nas mesmas.

• O avaliador verificará se, ao alterar o status do pedido na tela do cliente, o mesmo também é alterado na tela de detalhes do pedido da pessoa vendedora após atualização das páginas fazendo o processo de logout/login nas mesmas.

• O avaliador testará os data-testids referentes aos elementos do formulário de cadastro.

• O avaliador testará 4 situações aleatórias diferentes (uma para cada validação) de maneira isolada, sendo uma delas válida;
• O avaliador testará seu formulário com as 4 situações de maneira sequencial;
• O avaliador não vai executar o registro pelo botão de registro: ele validará se o botão ficará habilitado ou não, a depender dos critérios durante o input dos dados;
• É esperado que haja a validação dos dados durante a escrita dos mesmos.

• O avaliador tentará fazer a ação de cadastro com uma lista de pessoas (impressa durante o teste) com dados aleatórios válidos, validando-os posteriormente no banco de dados;
• Para cada pessoa, o avaliador espera que haja uma requisição POST para API ao clicar no Botão de registro, que retorne o status 201 - Created;
• Os dados dessa pessoa serão validados na tabela user do banco de dados.

• O avaliador tentará realizar o fluxo de cadastro anterior duas vezes, mas com apenas uma pessoa usuária gerada aleatoriamente.
• Na primeira vez o avaliador espera que haja uma requisição POST para API ao clicar no Botão de registro, que retorne o status 201 - Created;
• Na segunda vez o avaliador espera que haja uma requisição POST para API ao clicar no Botão de registro, que retorne o status 409 - Conflict;
• O avaliador espera que apareça na tela um elemento, antes oculto, com uma mensagem de erro qualquer.
  • Elemento: admin_manage__element-invalid-register.

• O avaliador testará os data-testids referentes aos elementos da tabela de pessoas usuárias;
• O avaliador tentará realizar o fluxo de cadastro com uma quantidade aleatória de pessoas usuárias válidas e verificará se as mesmas aparecem na tabela.

• O avaliador tentará realizar a remoção de itens validando-os na tabela.
  • O avaliador vai deletar uma quantidade aleatória de itens do carrinho (esses dados são impressos no teste).

• Serão validados os dados de cobertura no front-end e no back-end;

• Serão validados os dados de cobertura no front-end e no back-end;

• Serão validados os dados de cobertura no front-end e no back-end;