Giter Site home page Giter Site logo

exercises's Introduction

Hey, I'm Renato Álvares

  • Worked 3 years at Trybe, was a curriculum creator and reviewer and an instructor. I thought back and front-end technologies based on Javascript and a bit of Java and Python, as well as tooling for testing, CI/CD, dealing with SQL and NoSQL databases.
  • I studied Software Development at Trybe , the course included: Web Development Fundamentals, Front-end and Back-end Development, and also Computer Science.
  • I've been on program of initiation in teaching physics named PIBID at UFLA (Universidade Federal de Lavras) for over a year

Things I code with

NodeJS Git Docker Jest React Python MongoDB MySQL Sequelize Redux Java Vue.js Jinja Flask Postgres Shell Script TypeScript cypress Selenium Mocha C++ HTML5 CSS3 YAML Heroku

🌱 I’m currently learning

Elixir

⚡ Fun facts

  • ⛺ Was a scout
  • 🌈 Thought physics at state schools
  • 🗻 Like to climb
  • 🚲 Like to bike

📫 How to reach me

LinkedIn

exercises's People

Contributors

dependabot[bot] avatar nato-re avatar

exercises's Issues

#### 13 - Desenvolva a tela de produtos do cliente de forma que ela pressuponha dados válidos da pessoa usuária armazenados no localStorage

Observações técnicas

  • Após o login (e durante a navegação), deve-se manter os dados da pessoa usuária no localStorage, conforme o modelo:
{
  name: "Nome Da Pessoa Usuária",
  email: "[email protected]",
  role: "customer",
  token: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiTm9tZSBEYSBQZXNzb2EgVXN1w6FyaWEiLCJlbWFpbCI6ImVtYWlsQGRvbWluaW8uY29tIiwicm9sZSI6ImN1c3RvbWVyIn0.s5cmiyY16yViCXkHuzWekxkMeYBi75eT8uJnSbfadNE"
}
  • Sua página também deve ser capaz de deslogar a pessoa usuária que não possuir um token válido no localStorage
    • Note que aqui, é necessário que sua API seja capaz de gerar um token JWT, com base na chave em ./back-end/jwt.evaluation.key após um login válido.
    • Também será validado se esses dados são descartados ao logout.
O que será avaliado
  • 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.

#### 6 - Crie uma tela de registro que deve ser acessível via endpoint /register no navegador e pelo botão de registro na tela de login

Observações técnicas

  • Aqui deve-se garantir que a aplicação possui acesso a uma rota /register;
  • Também deve ser possível acessar a tela de registro clicando no botão de cadastro via tela de login.
O que será avaliado
  • 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.

#### 1 - Crie uma tela de login que deve ser acessível pelos endpoints / e /login no navegador

Observações técnicas

  • Aqui deve-se garantir que a aplicação possui acesso a uma rota /login;
  • A rota padrão (/) deve fazer redirecionamento para rota /login.
O que será avaliado
  • 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.

#### 10 - Desenvolva a tela de registro de maneira que ela impossibilite o cadastro de um usuário já existente

Observações técnicas

  • Sua página deve impedir o cadastro de pessoas com o mesmo Nome ou E-mail.
O que será avaliado
  • 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;

#### 13 - Desenvolva a tela de produtos do cliente de forma que ela pressuponha dados válidos da pessoa usuária armazenados no localStorage

Observações técnicas

  • Após o login (e durante a navegação), deve-se manter os dados da pessoa usuária no localStorage, conforme o modelo:
{
  name: "Nome Da Pessoa Usuária",
  email: "[email protected]",
  role: "customer",
  token: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiTm9tZSBEYSBQZXNzb2EgVXN1w6FyaWEiLCJlbWFpbCI6ImVtYWlsQGRvbWluaW8uY29tIiwicm9sZSI6ImN1c3RvbWVyIn0.s5cmiyY16yViCXkHuzWekxkMeYBi75eT8uJnSbfadNE"
}
  • Sua página também deve ser capaz de deslogar a pessoa usuária que não possuir um token válido no localStorage
    • Note que aqui, é necessário que sua API seja capaz de gerar um token JWT, com base na chave em ./back-end/jwt.evaluation.key após um login válido.
    • Também será validado se esses dados são descartados ao logout.
O que será avaliado
  • 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.

#### 4 - Desenvolva a tela de login de maneira que ela impossibilite o login com dados inexistentes no banco de dados

Observações técnicas

  • Sua página deve ser capaz de alertar a pessoa usuária de que aquele login é inválido após sua tentativa, já que apesar de formatado corretamente, os dados não existem no banco de dados.
O que será avaliado
  • 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

#### 12 - Desenvolva a tela de produtos do cliente criando os demais elementos com os data-testids disponíveis no protótipo

Observações técnicas

  • Se oriente pela seguinte tela do protótipo: Comum / Produtos;
  • Deve-se construir um total de 11 cards, cada um correspondente a um item da tabela produtos, conforme a tabela products do modelo em db.example.sql.
  • Os data-testid desses itens devem terminar com o id de cada produto, exemplo:
    • customer_products__element-card-price-1; customer_products__element-card-price-2; ...; customer_products__element-card-price-11.
O que será avaliado

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.

#### 8 - Desenvolva a tela de registro de maneira que ela impossibilite o cadastro com dados mal formatados

Observações técnicas

  • A senha recebe qualquer tipo de caractere;
  • Aqui, os critérios para considerar os dados mal formatados são:
    • Nome completo com número de caracteres menor que 12.
    • Email incompleto, fora de um padrão comum: <email>@<domínioPrincipal>.<domínioGenérico>;
    • Senha com número de caracteres menor que 6.
O que será avaliado
  • 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.

#### 5 - Desenvolva a tela de login de maneira que ela possibilite fazer o login com dados válidos e existentes no banco de dados

Observações técnicas

Sua página deve ser capaz de utilizar os dados do cliente previstos em db.example.sql:

  • Note que, a senha armazenada no banco é uma (hash md5)[https://pt.wikipedia.org/wiki/MD5], cuja tradução também está comentada no arquivo;
  • Sua API deve ser capaz de traduzir uma senha comum para uma hash md5, comparando-a e validando-a com a do banco de dados;
  • É possível utilizar bibliotecas de terceiros como a (md5)[https://www.npmjs.com/package/md5] ou a nativa crypto, para conversão de valores para md5.
O que será avaliado
  • 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;

#### 9 - Desenvolva a tela de registro de maneira que ela possibilite cadastrar com dados válidos

Observações técnicas

Sua página deve ser capaz de cadastrar pessoas usuárias com dados válidos:

  • Note que a senha deve ser armazenada no banco como uma (hash md5)[https://pt.wikipedia.org/wiki/MD5]. A tradução deve ocorrer na API;
  • É possível utilizar bibliotecas de terceiros como a (md5)[https://www.npmjs.com/package/md5] ou a nativa crypto, para conversão de valores para md5.
O que será avaliado
  • 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.

#### 11 - Crie uma tela de produtos do cliente contendo uma barra de navegação - navbar -, que servirá também para demais telas das pessoas usuárias

Observações técnicas

O que será avaliado

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.

#### 11 - Crie uma tela de produtos do cliente contendo uma barra de navegação - navbar -, que servirá também para demais telas das pessoas usuárias

Observações técnicas

O que será avaliado

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.

#### 20 - Desenvolva a tela de checkout do cliente de forma a nos redirecionar para a tela de detalhes do pedido após a finalização do mesmo

Observações técnicas

  • Não se preocupe aqui em ter a tela de detalhes do pedido pronta: o que deve estar garantido, é que é possível ter acesso a uma rota localhost:3000/customer/orders/<id> no front, onde o id é retornado da requisição da venda;
  • Ao final do pedido (ao clicar no 'Botão de finalização do pedido'), a tela de checkout deve disparar uma requisição para a API, inserindo a venda e retornando o id da mesma, para utilização no redirecionamento.
O que será avaliado
  • 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.

#### 3 - Desenvolva a tela de login de maneira que ela impossibilite o login com dados mal formatados

Observações técnicas

  • A senha recebe qualquer tipo de caractere;
  • Aqui, os critérios para considerar dados de login mal formatados são:
    • Email incompleto, fora de um padrão comum como: <email>@<domínioPrincipal>.<domínioGenérico>;
    • Senha com número de caracteres menor que 6.
O que será avaliado
  • 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.

#### 14 - Desenvolva a tela de produtos do cliente de forma que os cards de todos os produtos pré-cadastrados contenham os valores corretos

Observações técnicas

  • Há um total de 11 cards, cada um correspondente a um item da tabela produtos, conforme a tabela products do modelo em db.example.sql;
  • Os dados desses produtos devem condizer com os dados do banco de dados;
  • Nesse requisito, deve-se garantir que as imagens dos produtos estejam disponíveis para acesso direto via rota estática na sua API.
O que será avaliado
  • 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.

#### 3 - Desenvolva a tela de login de maneira que ela impossibilite o login com dados mal formatados

Observações técnicas

  • A senha recebe qualquer tipo de caractere;
  • Aqui, os critérios para considerar dados de login mal formatados são:
    • Email incompleto, fora de um padrão comum como: <email>@<domínioPrincipal>.<domínioGenérico>;
    • Senha com número de caracteres menor que 6.
O que será avaliado
  • 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.

#### 15 - Desenvolva a tela de produtos do cliente de forma que o preço total esteja correto após a adição de itens aleatórios

Observações técnicas

  • Cada card deve possibilitar a adição, remoção ou definição manual da quantidade de itens de cada produto
    • Esses itens devem compor um "carrinho de compras", que deve ser persistente no fluxo do cliente até o momento do checkout (quando o carrinho se torna uma venda concretizada);

👀De olho nas dicas:

  • Considere utilizar o localStorage como forma de armazenar uma entidade carrinho;
  • Considere a utilização de um contexto específico para acessar e manipular esses dados (tirando essa competência dos componentes filho). Esse contexto não deve ser geral, ou seja, não deve ser acessado por outras páginas fora do escopo do cliente.
  • Para facilitar o processo, considere o carrinho como um 'modelo' de uma entidade banco de dados, mas programado no front-end (por ser temporário). Esses dados não devem persistir ao logout.
  • O valor total do pedido é a soma dos resultados das quantidades de cada item, multiplicada pelo preço unitário dos mesmos.
O que será avaliado
  • 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.

#### 14 - Desenvolva a tela de produtos do cliente de forma que os cards de todos os produtos pré-cadastrados contenham os valores corretos

Observações técnicas

  • Há um total de 11 cards, cada um correspondente a um item da tabela produtos, conforme a tabela products do modelo em db.example.sql;
  • Os dados desses produtos devem condizer com os dados do banco de dados;
  • Nesse requisito, deve-se garantir que as imagens dos produtos estejam disponíveis para acesso direto via rota estática na sua API.
O que será avaliado
  • 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.

#### 4 - Desenvolva a tela de login de maneira que ela impossibilite o login com dados inexistentes no banco de dados

Observações técnicas

  • Sua página deve ser capaz de alertar a pessoa usuária de que aquele login é inválido após sua tentativa, já que apesar de formatado corretamente, os dados não existem no banco de dados.
O que será avaliado
  • 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

#### 17 - Crie uma tela de checkout do cliente com elementos com os data-testids disponíveis no protótipo

Observações técnicas

  • Se oriente pela seguinte tela do protótipo: Comum / Checkout;
  • A quantidade de itens no checkout deve corresponder à quantidade de itens no recorte aleatório de produtos utilizados no teste;
  • Aqui, a referência de identificação dos campos das linhas da tabela deve ser o índice (index) da matriz (array) dos produtos no carrinho de compras. Por exemplo:
    • element-order-table-name-0; element-order-table-name-1; ...; element-order-table-name-x.
O que será avaliado
  • O avaliador testará os data-testids referentes aos itens do carrinho e demais elementos.

#### 17 - Crie uma tela de checkout do cliente com elementos com os data-testids disponíveis no protótipo

Observações técnicas

  • Se oriente pela seguinte tela do protótipo: Comum / Checkout;
  • A quantidade de itens no checkout deve corresponder à quantidade de itens no recorte aleatório de produtos utilizados no teste;
  • Aqui, a referência de identificação dos campos das linhas da tabela deve ser o índice (index) da matriz (array) dos produtos no carrinho de compras. Por exemplo:
    • element-order-table-name-0; element-order-table-name-1; ...; element-order-table-name-x.
O que será avaliado
  • O avaliador testará os data-testids referentes aos itens do carrinho e demais elementos.

#### 5 - Desenvolva a tela de login de maneira que ela possibilite fazer o login com dados válidos e existentes no banco de dados

Observações técnicas

Sua página deve ser capaz de utilizar os dados do cliente previstos em db.example.sql:

  • Note que, a senha armazenada no banco é uma (hash md5)[https://pt.wikipedia.org/wiki/MD5], cuja tradução também está comentada no arquivo;
  • Sua API deve ser capaz de traduzir uma senha comum para uma hash md5, comparando-a e validando-a com a do banco de dados;
  • É possível utilizar bibliotecas de terceiros como a (md5)[https://www.npmjs.com/package/md5] ou a nativa crypto, para conversão de valores para md5.
O que será avaliado
  • 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;

#### 10 - Desenvolva a tela de registro de maneira que ela impossibilite o cadastro de um usuário já existente

Observações técnicas

  • Sua página deve impedir o cadastro de pessoas com o mesmo Nome ou E-mail.
O que será avaliado
  • 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;

#### 16 - Desenvolva a tela de produtos do cliente de forma que haja um botão de carrinho que redirecionará para a tela de checkout caso itens sejam adicionados

Observações técnicas

  • Sua página deve garantir que alterações no carrinho também mudem o valor total da venda:
    👀De olho na dica: tire proveito do contexto específico mencionado anteriormente para realizar a lógica e fornecer o resultado do cálculo.
O que será avaliado
  • 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.

#### 8 - Desenvolva a tela de registro de maneira que ela impossibilite o cadastro com dados mal formatados

Observações técnicas

  • A senha recebe qualquer tipo de caractere;
  • Aqui, os critérios para considerar os dados mal formatados são:
    • Nome completo com número de caracteres menor que 12.
    • Email incompleto, fora de um padrão comum: <email>@<domínioPrincipal>.<domínioGenérico>;
    • Senha com número de caracteres menor que 6.
O que será avaliado
  • 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.

#### 16 - Desenvolva a tela de produtos do cliente de forma que haja um botão de carrinho que redirecionará para a tela de checkout caso itens sejam adicionados

Observações técnicas

  • Sua página deve garantir que alterações no carrinho também mudem o valor total da venda:
    👀De olho na dica: tire proveito do contexto específico mencionado anteriormente para realizar a lógica e fornecer o resultado do cálculo.
O que será avaliado
  • 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.

#### 1 - Crie uma tela de login que deve ser acessível pelos endpoints / e /login no navegador

Observações técnicas

  • Aqui deve-se garantir que a aplicação possui acesso a uma rota /login;
  • A rota padrão (/) deve fazer redirecionamento para rota /login.
O que será avaliado
  • 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.

#### 6 - Crie uma tela de registro que deve ser acessível via endpoint /register no navegador e pelo botão de registro na tela de login

Observações técnicas

  • Aqui deve-se garantir que a aplicação possui acesso a uma rota /register;
  • Também deve ser possível acessar a tela de registro clicando no botão de cadastro via tela de login.
O que será avaliado
  • 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.

#### 12 - Desenvolva a tela de produtos do cliente criando os demais elementos com os data-testids disponíveis no protótipo

Observações técnicas

  • Se oriente pela seguinte tela do protótipo: Comum / Produtos;
  • Deve-se construir um total de 11 cards, cada um correspondente a um item da tabela produtos, conforme a tabela products do modelo em db.example.sql.
  • Os data-testid desses itens devem terminar com o id de cada produto, exemplo:
    • customer_products__element-card-price-1; customer_products__element-card-price-2; ...; customer_products__element-card-price-11.
O que será avaliado

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.

#### 15 - Desenvolva a tela de produtos do cliente de forma que o preço total esteja correto após a adição de itens aleatórios

Observações técnicas

  • Cada card deve possibilitar a adição, remoção ou definição manual da quantidade de itens de cada produto
    • Esses itens devem compor um "carrinho de compras", que deve ser persistente no fluxo do cliente até o momento do checkout (quando o carrinho se torna uma venda concretizada);

👀De olho nas dicas:

  • Considere utilizar o localStorage como forma de armazenar uma entidade carrinho;
  • Considere a utilização de um contexto específico para acessar e manipular esses dados (tirando essa competência dos componentes filho). Esse contexto não deve ser geral, ou seja, não deve ser acessado por outras páginas fora do escopo do cliente.
  • Para facilitar o processo, considere o carrinho como um 'modelo' de uma entidade banco de dados, mas programado no front-end (por ser temporário). Esses dados não devem persistir ao logout.
  • O valor total do pedido é a soma dos resultados das quantidades de cada item, multiplicada pelo preço unitário dos mesmos.
O que será avaliado
  • 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.

#### 9 - Desenvolva a tela de registro de maneira que ela possibilite cadastrar com dados válidos

Observações técnicas

Sua página deve ser capaz de cadastrar pessoas usuárias com dados válidos:

  • Note que a senha deve ser armazenada no banco como uma (hash md5)[https://pt.wikipedia.org/wiki/MD5]. A tradução deve ocorrer na API;
  • É possível utilizar bibliotecas de terceiros como a (md5)[https://www.npmjs.com/package/md5] ou a nativa crypto, para conversão de valores para md5.
O que será avaliado
  • 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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.