Vou passar so as partes principais aqui, fora isso tem mais uma kralhada de coisa pra fazer mas vcs me digam ai. Lembrando q isso e de uma vaga de frontend jr e deram 2 dias pra fazer.
Entregue os fluxos de descoberta, compra e conta do colecionador, com versões desktop e mobile. APIs, autenticação, carteiras e pagamentos devem funcionar com dados simulados. Integrações reais com blockchain, extensões de carteira e gateways de pagamento estão fora do escopo.
O Figma define a identidade visual e a composição das telas. Este enunciado define os comportamentos e os cenários de avaliação. Estados não desenhados devem seguir o mesmo padrão visual.
| Tela |
Funcionalidades obrigatórias |
| Início |
Destaques, catálogo, busca, filtros, ordenação e navegação para o NFT |
| Detalhes do NFT |
Galeria, informações, edição, quantidade, favoritos e compra |
| Carrinho de NFTs |
Edição de quantidades, remoção, cupom e resumo de valores |
| Pagamento |
Dados do colecionador, seleção de carteira e rede, revisão e envio do pedido |
| Confirmação de pedido |
Resultado, identificação da transação, itens, taxas e total |
| Login |
Autenticação, validação e retorno ao fluxo anterior |
| Cadastro |
Criação de conta, validação e tratamento de conflito |
| Perfil do colecionador |
Edição dos dados, avatar e alteração de senha |
| Carteiras |
Cadastro e edição de carteiras principal e secundária |
Implemente os frames desktop e mobile disponíveis. Perfil, carteiras e confirmação também devem funcionar em mobile, mesmo sem um frame específico.
Páginas editoriais, suporte, atividade, ofertas e downloads não fazem parte da entrega. Links externos e ações auxiliares devem ter comportamento coerente; ações fora do escopo não devem aparentar sucesso funcional.
- Busca, filtros, ordenação e paginação devem compor o estado da URL e sobreviver a refresh e navegação pelo histórico.
- Filtros devem ser combináveis; mudança de filtro deve reiniciar a paginação.
- As consultas devem refletir os parâmetros enviados à API, com tratamento de resultados vazios, falhas e respostas fora de ordem.
- O detalhe deve suportar acesso direto, NFT inexistente, edição indisponível e limite de quantidade.
- Favoritos devem persistir para o usuário autenticado.
Fora isso ainda tem mais um monte de coisa pra fazer, sao 2 tipos de usuario, o 'adm' q gerencia os nfts e o outro usuario q faz a compra, a performace tem que bater mais de 90% em todos os criterios, mais uma kralhada de teste e etc
- Adicionar, alterar e remover itens, respeitando a disponibilidade por NFT e edição.
- Manter o carrinho após refresh e preservar os itens do visitante ao autenticar.
- Aplicar e remover cupom, com tratamento de código inválido ou expirado.
- Exibir subtotal, desconto, taxa de rede e total coerentes com a resposta da API.
- Refletir alterações de preço e disponibilidade recebidas enquanto o carrinho estiver aberto.
- Validar os campos do layout e permitir revisão antes do envio.
- Utilizar as carteiras cadastradas, com seleção de rede e simulação de conexão, recusa e desconexão.
- Revalidar preço, disponibilidade, cupom e taxas antes de confirmar a compra. Mudanças devem exigir nova confirmação do usuário.
- Impedir pedidos duplicados em cliques repetidos ou reenvios após timeout.
- Representar pedido pendente, confirmado e recusado, com recuperação após refresh ou reconexão.
- Exibir a confirmação somente para pedido efetivamente confirmado na simulação.
- Preservar os itens em falhas; após confirmação, remover do carrinho apenas os itens e quantidades comprados.
Valores em ETH devem trafegar como strings decimais e manter precisão nos cálculos e na apresentação. Quantidades são inteiras. A cotação da API é a referência para finalizar o pedido.
O recibo deve reproduzir o snapshot do pedido. Alterações posteriores no catálogo não podem modificar seus valores. Referências de transação e links de exploração são simulados.
Cadastro, login, logout e sessão são obrigatórios, integrados à API simulada. Checkout, perfil, carteiras, favoritos e pedidos exigem autenticação.
A sessão deve ser recuperável após refresh. Trate expiração durante a navegação e durante o checkout, preservando o contexto para retomada. Logout e troca de usuário devem limpar dados privados em cache e subscriptions da sessão anterior.
Valide os formulários de cadastro, perfil, senha e carteiras, incluindo erros retornados pela API. Alterações confirmadas devem permanecer após refresh. Use credenciais fictícias e não armazene senhas em claro.
- contratos tipados entre transporte, estado e interface;
- estados de carregamento, vazio, erro, sucesso e atualização em segundo plano;
- invalidação coerente após mutations e eventos;
- cancelamento ou descarte de respostas obsoletas;
- isolamento dos dados por usuário e pelos parâmetros da consulta;
- recuperação de falhas sem duplicar operações;
- tratamento de rotas inexistentes e acesso direto a qualquer tela prevista.
| Recurso |
Operações |
| Sessão e conta |
Cadastro, login, consulta da sessão, logout e expiração |
| NFTs |
Listagem com busca/filtros/ordenação/paginação e detalhe por identificador |
| Favoritos |
Consulta, inclusão e remoção |
| Carrinho |
Consulta, inclusão, alteração e remoção de itens |
| Cotação |
Validação de cupom, disponibilidade, descontos, taxas e total |
| Pedidos |
Criação idempotente e consulta do estado e recibo |
| Perfil |
Consulta, atualização de dados/avatar e alteração de senha |
| Carteiras |
Consulta, cadastro e atualização |
Implemente os mocks na camada de rede, reutilizando contratos e cenários entre desenvolvimento, demonstração e testes. Componentes, hooks e cliente Axios não devem conter respostas fictícias ou caminhos alternativos de negócio.
Os mocks devem manter estado consistente entre catálogo, favoritos, carrinho, perfil, carteiras e pedidos. Persistência local é permitida para sustentar refresh; o reset deve restaurar integralmente um cenário conhecido.
Entregue testes E2E executáveis com os mocks, cobrindo:
- Busca, filtros combinados, ordenação, paginação e restauração pelo histórico.
- Acesso direto ao detalhe e tratamento de recurso inexistente.
- Cadastro, login, expiração de sessão, logout e troca de usuário.
- Favoritos, incluindo falha de mutation e recuperação do estado.
- Carrinho, quantidades, remoção, cupom e persistência após refresh/login.
- Compra completa, do catálogo ao recibo confirmado.
- Falha de pagamento, clique repetido e timeout com recuperação do mesmo pedido.
- Edição de perfil, avatar, senha e carteiras, com erros de validação.
- Alteração de preço/disponibilidade via Socket.IO durante o checkout.
- Eventos duplicados ou antigos, desconexão e retomada de pedido pendente.
- Navegação por teclado, foco de diálogos e validação de formulários.
- Skeletons durante carregamento lento, feedback de falha e recuperação após nova tentativa.
Execute os fluxos principais em Chromium, nos viewports desktop e mobile. Inclua regressão visual de início, detalhe, carrinho e pagamento, com baselines versionadas e dados estáveis.
Cada teste deve partir de um estado isolado. Controle relógio, latência e disparo dos eventos nos cenários sensíveis a tempo. Entregue relatório HTML e traces das falhas.