Casos de Teste

Versão: 1.0 Escopo: Documento único contendo todos os casos de teste do projeto.

TC-001

• < Backward: TASK-001
• Título: Validação de criação de caderno na raiz via API
• Pré-condição: Estar autenticado no sistema com permissões válidas.
• Passos:
  • Enviar uma requisição POST /api/notebooks com o corpo contendo o nome válido do caderno.
• Resultado esperado:
  • O status HTTP retornado deve ser de sucesso (ex: 201 Created).
  • O caderno deve ser devidamente persistido na raiz organizacional do banco de dados.

TC-002

• < Backward: TASK-002
• Título: Validação da interface de criação de caderno
• Pré-condição: Estar na tela principal do sistema.
• Passos:
  • Acionar a opção de criar novo caderno.
  • Preencher o nome do caderno no formulário exibido.
  • Confirmar a operação de salvamento.
• Resultado esperado:
  • O modal ou formulário deve ser fechado e o novo caderno deve aparecer visível na interface.

TC-003

• < Backward: TASK-003
• Título: Validação da listagem de cadernos
• Pré-condição: Existir ao menos um caderno cadastrado na conta do usuário.
• Passos:
  • Acessar o módulo de listagem de cadernos ou disparar a requisição GET /api/notebooks.
• Resultado esperado:
  • O sistema deve retornar e exibir todos os cadernos criados pelo usuário na interface organizacional.

TC-004

• < Backward: TASK-004
• Título: Validação do endpoint de captura rápida na Inbox
• Pré-condição: Estar autenticado.
• Passos:
  • Enviar requisição POST /api/inbox com uma descrição de texto válida.
• Resultado esperado:
  • O item deve ser armazenado com sucesso na base de dados com o estado inicial de Inbox e sem nenhum vínculo obrigatório a cadernos.

TC-005

• < Backward: TASK-005
• Título: Validação da interface de input rápido na Inbox
• Pré-condição: Estar na tela da Inbox.
• Passos:
  • Digitar um texto no campo de input dedicado à captura rápida.
  • Submeter o registro.
• Resultado esperado:
  • O item deve ser registrado instantaneamente sem fricção e exibido na listagem da Inbox.

TC-006

• < Backward: TASK-006
• Título: Validação de visualização dos registros da Inbox
• Pré-condição: Existir itens capturados na Inbox.
• Passos:
  • Acessar a área da Inbox ou disparar GET /api/inbox.
• Resultado esperado:
  • Todos os itens atualmente presentes na área temporária de captura devem ser listados corretamente.

TC-007

• < Backward: TASK-007
• Título: Validação da classificação de item da Inbox para Caderno via API
• Pré-condição: Existir um item na Inbox e um caderno válido criado.
• Passos:
  • Enviar requisição PATCH /api/items/{id}/classify informando o ID do caderno de destino.
• Resultado esperado:
  • O estado do item deve mudar de Inbox para Ativo e o ID do caderno correspondente deve ser gravado.

TC-008

• < Backward: TASK-008
• Título: Validação visual da movimentação da Inbox para Caderno
• Pré-condição: Estar visualizando os itens da Inbox com cadernos disponíveis.
• Passos:
  • Arrastar o item para o caderno ou selecioná-lo através do menu de classificação.
• Resultado esperado:
  • O item deve sumir instantaneamente da listagem da Inbox e passar a pertencer ao caderno selecionado.

TC-009

• < Backward: TASK-009
• Título: Validação de unicidade de relacionamento item-caderno no banco de dados
• Pré-condição: Estar conectado ao banco de dados ou ambiente de teste de integridade.
• Passos:
  • Tentar associar um item pós-classificado a um segundo caderno simultaneamente ou inserir chave nula em desacordo com as regras.
• Resultado esperado:
  • O modelo relacional deve rejeitar a operação, impedindo múltiplos cadernos ou ausência de vínculo após a classificação.

TC-010

• < Backward: TASK-010
• Título: Validação de criação de item TODO via API
• Pré-condição: Estar autenticado e possuir um caderno válido.
• Passos:
  • Enviar requisição POST /api/items informando o tipo TODO, título e campos opcionais (due date/horário).
• Resultado esperado:
  • O item deve ser criado com a flag is_completed inicializada como falsa por padrão.

TC-011

• < Backward: TASK-011
• Título: Validação do formulário de criação de TODO na interface
• Pré-condição: Estar dentro de um caderno.
• Passos:
  • Abrir o formulário de criação de item TODO.
  • Preencher os campos opcionais de horário e data limite e salvar.
• Resultado esperado:
  • O item TODO deve ser criado e exibido corretamente na listagem com os parâmetros informados.

TC-012

• < Backward: TASK-012
• Título: Validação de restrição de campos obrigatórios para SCHEDULE via API
• Pré-condição: Estar autenticado.
• Passos:
  • Enviar requisição POST /api/items do tipo SCHEDULE omitindo os campos de data/hora de início ou término.
• Resultado esperado:
  • O backend deve recusar a criação retornando erro de validação.

TC-013

• < Backward: TASK-013
• Título: Validação de obrigatoriedade temporal para SCHEDULE no frontend
• Pré-condição: Estar criando um item do tipo SCHEDULE na interface.
• Passos:
  • Tentar submeter o formulário sem preencher a data/hora de início e término.
• Resultado esperado:
  • A interface deve bloquear o envio e exibir alertas de preenchimento obrigatório dos campos temporais.

TC-014

• < Backward: TASK-014
• Título: Validação de relacionamento opcional de TODO com SCHEDULE
• Pré-condição: Existir um item SCHEDULE criado.
• Passos:
  • Criar ou editar um item TODO enviando o campo schedule_id apontando para o SCHEDULE existente.
• Resultado esperado:
  • O banco de dados deve persistir a chave estrangeira unidirecional de forma bem-sucedida.

TC-015

• < Backward: TASK-015
• Título: Validação de inserção de sub-item via API
• Pré-condição: Existir um item do tipo TODO criado.
• Passos:
  • Enviar requisição POST /api/items/{todo_id}/subitems com a descrição do sub-item.
• Resultado esperado:
  • O sub-item deve ser gravado e vinculado estritamente ao ID do TODO pai.

TC-016

• < Backward: TASK-016
• Título: Validação do componente de checklist de sub-itens e restrição de SCHEDULE
• Pré-condição: Possuir um TODO e um SCHEDULE visíveis na interface.
• Passos:
  • Selecionar o item SCHEDULE e verificar a seção de sub-itens.
  • Selecionar o item TODO e adicionar um sub-item pela interface.
• Resultado esperado:
  • Para o SCHEDULE, a opção de sub-itens deve estar oculta ou bloqueada. Para o TODO, o sub-item deve ser adicionado com sucesso.

TC-017

• < Backward: TASK-017
• Título: Validação de escopo isolado de sub-itens
• Pré-condição: Existir um TODO com sub-itens cadastrados.
• Passos:
  • Concluir um sub-item específico na interface.
• Resultado esperado:
  • O sistema deve atualizar apenas o estado interno daquele sub-item sem propagar alteração global para outros TODOs ou tarefas.

TC-018

• < Backward: TASK-018
• Título: Validação de endpoint de duplicação seletiva de itens
• Pré-condição: Existir um item criado com título, caderno e prioridade definidos.
• Passos:
  • Enviar requisição POST /api/items/{id}/duplication.
• Resultado esperado:
  • Um novo registro deve ser gerado copiando o título (com o prefixo “Cópia de”), o caderno de origem e a prioridade.

TC-019

• < Backward: TASK-019
• Título: Validação de propriedades iniciais padrão na duplicação
• Pré-condição: Ter executado a duplicação de um item que continha datas preenchidas.
• Passos:
  • Consultar as propriedades do item recém-duplicado.
• Resultado esperado:
  • O registro clonado deve nascer no estado ATIVO e sem nenhuma data preenchida.

TC-020

• < Backward: TASK-020
• Título: Validação de omissão de propriedades secundárias na duplicação
• Pré-condição: Ter um item original concluído, com sub-itens e vinculado a um SCHEDULE.
• Passos:
  • Duplicar este item e inspecionar o resultado.
• Resultado esperado:
  • O item duplicado não deve herdar o status de conclusão, os sub-itens e nem o vínculo com o SCHEDULE.

TC-021

• < Backward: TASK-021
• Título: Validação de exclusão de item sem sub-itens via API
• Pré-condição: Existir um item sem sub-itens.
• Passos:
  • Enviar requisição DELETE /api/items/{id}.
• Resultado esperado:
  • O registro deve ser apagado da base de dados com sucesso, sem exigências de validações extras.

TC-022

• < Backward: TASK-022
• Título: Validação de exclusão direta na interface para itens sem dependências
• Pré-condição: Visualizar um item sem sub-itens na listagem.
• Passos:
  • Clicar no botão de deletar o item.
• Resultado esperado:
  • O item deve ser removido da tela imediatamente.

TC-023

• < Backward: TASK-023
• Título: Validação de detecção de sub-itens na pré-deleção via API
• Pré-condição: Existir um TODO com sub-itens vinculados.
• Passos:
  • Enviar requisição DELETE /api/items/{id} para este item.
• Resultado esperado:
  • O backend deve identificar a dependência e retornar flag indicando a necessidade de confirmação ou gerenciar a cascata controlada.

TC-024

• < Backward: TASK-024
• Título: Validação do modal de confirmação de exclusão para TODOs com sub-itens
• Pré-condição: Tentar deletar um TODO com sub-itens pela interface.
• Passos:
  • Acionar a exclusão do item e observar o comportamento da tela.
  • Confirmar a exclusão no alerta exibido.
• Resultado esperado:
  • Um modal de aviso deve ser apresentado alertando sobre a remoção conjunta dos sub-itens, e após a confirmação, tudo deve ser excluído.

TC-025

• < Backward: TASK-025
• Título: Validação de transição manual para o estado Arquivado via API
• Pré-condição: Existir um item que esteja no estado Concluído.
• Passos:
  • Enviar requisição PATCH /api/items/{id}/archive.
• Resultado esperado:
  • O backend deve alterar o estado do item para Arquivado com sucesso.

TC-026

• < Backward: TASK-026
• Título: Validação da restrição de arquivamento estritamente manual na interface
• Pré-condição: Possuir itens em diferentes estados (pendente, concluído).
• Passos:
  • Verificar a disponibilidade do botão de arquivo em itens pendentes e em itens concluídos.
  • Acionar o arquivamento manual no item concluído.
• Resultado esperado:
  • O botão de arquivar deve estar disponível apenas para itens concluídos e a ação nunca deve ocorrer de forma automática pelo sistema.

TC-027

• < Backward: TASK-027
• Título: Validação de cálculo de recorrência básica no modelo
• Pré-condição: Criar um item com regra de recorrência configurada (diária, semanal ou mensal).
• Passos:
  • Inspecionar a geração ou persistência das instâncias baseadas na frequência e data de término.
• Resultado esperado:
  • O sistema deve calcular e estruturar as recorrências corretamente para SCHEDULEs e TODOs.

TC-028

• < Backward: TASK-028
• Título: Validação de componentes visuais de recorrência
• Pré-condição: Abrir o formulário de criação/edição de item.
• Passos:
  • Selecionar uma opção de recorrência (diária, semanal ou mensal) e definir uma data de término opcional.
• Resultado esperado:
  • Os seletores visuais devem registrar corretamente a preferência e aplicá-la ao salvar.

TC-029

• < Backward: TASK-029
• Título: Validação da restrição contra edições de instâncias isoladas de recorrência
• Pré-condição: Possuir uma série recorrente ativa no sistema.
• Passos:
  • Tentar editar ou cancelar uma única ocorrência isolada gerada pela série.
• Resultado esperado:
  • O sistema não deve expor opções de override ou exceções pontuais, respeitando a limitação do escopo da V1.

TC-030

• < Backward: TASK-030
• Título: Validação do endpoint de Snooze com atalhos rápidos
• Pré-condição: Existir um item ativo.
• Passos:
  • Enviar requisição PATCH /api/items/{id}/snooze aplicando os atalhos rápidos (ex: amanhã, 3 dias, próxima semana).
• Resultado esperado:
  • O backend deve atualizar adequadamente a data de reaparecimento do item.

TC-031

• < Backward: TASK-031
• Título: Validação visual do menu de Snooze rápido e ocultação temporária
• Pré-condição: Visualizar a listagem de tarefas ativas.
• Passos:
  • Selecionar a opção de adiar um item utilizando um atalho rápido.
• Resultado esperado:
  • O item deve ser ocultado temporariamente da listagem padrão até que a data estipulada seja atingida.

TC-032

• < Backward: TASK-032
• Título: Validação de adiamento por data manual customizada
• Pré-condição: Acessar as opções de adiamento de um item.
• Passos:
  • Escolher a inserção de uma data específica manual no calendário de Snooze e confirmar.
• Resultado esperado:
  • O sistema deve aceitar a data escolhida e programar o reaparecimento do item exatamente para o dia estipulado.

TC-033

• < Backward: TASK-033
• Título: Validação da renderização da Visão Diária do Calendário
• Pré-condição: Possuir compromissos e tarefas com horários no dia atual.
• Passos:
  • Acessar o módulo de Calendário e alternar para o modo de Visão Diária.
• Resultado esperado:
  • A interface deve renderizar corretamente a timeline vertical de 24 horas exibindo os blocos temporais corretos.

TC-034

• < Backward: TASK-034
• Título: Validação do endpoint GET /api/calendar/daily
• Pré-condição: Estar autenticado com dados criados no dia.
• Passos:
  • Requisitar a API de dados diários do calendário com GET /api/calendar/daily.
• Resultado esperado:
  • O retorno deve conter dados agregados válidos contendo SCHEDULEs e TODOs qualificados por horário ou data.

TC-035

• < Backward: TASK-035
• Título: Validação de alternância entre visões Semanal, Mensal e Agenda
• Pré-condição: Estar no módulo de Calendário.
• Passos:
  • Alternar sucessivamente entre os modos Semanal, Mensal e Agenda na interface.
• Resultado esperado:
  • O frontend deve suportar a transição fluida entre as quatro visões temporais sem erros de renderização.

TC-036

• < Backward: TASK-036
• Título: Validação dos endpoints de agregação de calendário
• Pré-condição: Estar autenticado.
• Passos:
  • Disparar requisições para GET /api/calendar/weekly, monthly e agenda.
• Resultado esperado:
  • Cada endpoint deve retornar os dados estruturados de acordo com os limites temporais de sua respectiva visão.

TC-037

• < Backward: TASK-037
• Título: Validação das regras de exibição cruzada de itens no calendário
• Pré-condição: Ter no sistema: SCHEDULEs, TODOs com data/horário e TODOs sem nenhuma data.
• Passos:
  • Inspecionar a renderização nas telas de calendário.
• Resultado esperado:
  • SCHEDULEs devem aparecer sempre; TODOs devem aparecer apenas se tiverem horário ou due date; TODOs sem data devem ser rigorosamente omitidos.

TC-038

• < Backward: TASK-038
• Título: Validação do endpoint do Planner Diário
• Pré-condição: Estar autenticado.
• Passos:
  • Requisitar GET /api/planner/daily para um dia específico.
• Resultado esperado:
  • A API deve retornar todos os TODOs do dia selecionado juntamente com os TODOs que não possuem data associada.

TC-039

• < Backward: TASK-039
• Título: Validação da tela do Planner Diário na interface
• Pré-condição: Acessar o módulo de Planner Diário.
• Passos:
  • Verificar o agrupamento dos itens apresentados em tela.
• Resultado esperado:
  • A interface deve exibir de forma unificada as tarefas diárias e as pendências sem data.

TC-040

• < Backward: TASK-040
• Título: Validação de omissão estrita de SCHEDULEs no Planner Diário
• Pré-condição: Existir itens do tipo SCHEDULE cadastrados no sistema.
• Passos:
  • Acessar o Planner Diário e buscar por qualquer SCHEDULE cadastrado.
• Resultado esperado:
  • Nenhuma consulta ou renderização do Planner Diário pode incluir instâncias de SCHEDULE.

TC-041

• < Backward: TASK-041
• Título: Validação de busca textual por termo no título via API
• Pré-condição: Existir cadernos, SCHEDULEs e TODOs contendo termos comuns.
• Passos:
  • Executar requisição GET /api/search?q=termo.
• Resultado esperado:
  • A consulta deve retornar correspondências estritamente nos títulos de itens do tipo TODO, ignorando cadernos e SCHEDULEs.

TC-042

• < Backward: TASK-042
• Título: Validação da barra de busca simples na interface
• Pré-condição: Estar na tela de busca.
• Passos:
  • Digitar termos de pesquisa na barra de busca simples.
• Resultado esperado:
  • A interface deve exibir em tempo real os resultados filtrados estritamente correspondentes a TODOs.

TC-043

• < Backward: TASK-043
• Título: Validação de filtros combinados na busca via API
• Pré-condição: Possuir diversos TODOs com status, cadernos, prioridades e períodos variados.
• Passos:
  • Enviar requisição para o endpoint de busca informando parâmetros adicionais de filtro (status, caderno, prioridade, período).
• Resultado esperado:
  • O backend deve refinar e retornar o dataset correspondente à intersecção dos filtros aplicados.

TC-044

• < Backward: TASK-044
• Título: Validação dos componentes visuais de filtro na interface de busca
• Pré-condição: Estar visualizando os resultados de uma busca.
• Passos:
  • Selecionar opções nos filtros visuais de status, cadernos, prioridades e intervalo de datas.
• Resultado esperado:
  • A listagem de resultados exibida em tela deve ser atualizada instantaneamente respeitando os filtros selecionados.

TC-045

• < Backward: TASK-045
• Título: Validação de ordenação por critérios específicos no Todo List
• Pré-condição: Possuir uma lista de tarefas ativas.
• Passos:
  • Alternar entre os critérios de ordenação disponíveis (Manual/Drag & Drop, Prioridade, Data limite, Criação, Estimativa e Caderno).
• Resultado esperado:
  • A listagem deve reorganizar dinamicamente os elementos de acordo com a regra escolhida.

TC-046

• < Backward: TASK-046
• Título: Validação dos seletores de ordenação e modo manual na UI
• Pré-condição: Estar na listagem do Todo List.
• Passos:
  • Selecionar o modo manual e alterar a posição de um item arrastando-o (drag & drop).
• Resultado esperado:
  • A nova posição personalizada deve ser aceita e persistida na interface.

TC-047

• < Backward: TASK-047
• Título: Validação da regra de ordenação estrutural padrão no backend
• Pré-condição: Existir uma listagem sem parâmetros de ordenação informados pelo usuário.
• Passos:
  • Executar a consulta padrão de listagem de tarefas.
• Resultado esperado:
  • A consulta SQL deve ordenar rigorosamente os registros obedecendo à hierarquia padrão: prioridade > data limite > data de criação.

TC-048

• < Backward: TASK-048
• Título: Validação do endpoint de atualização de dados cadastrais
• Pré-condição: Estar autenticado com uma conta de usuário válida.
• Passos:
  • Enviar requisição PUT /api/user/account com novos dados pessoais válidos.
• Resultado esperado:
  • O sistema deve validar e persistir com segurança as alterações no perfil do usuário.

TC-049

• < Backward: TASK-049
• Título: Validação da tela de configurações de conta e reflexão global
• Pré-condição: Acessar o módulo de Configurações na interface.
• Passos:
  • Atualizar as informações de perfil na tela e salvar.
• Resultado esperado:
  • As modificações devem ser salvas com sucesso e refletidas instantaneamente na identificação global do usuário em toda a plataforma.

TC-050

• < Backward: TASK-050
• Título: Validação de autenticação de usuário via API
• Pré-condição: Possuir uma conta cadastrada e ativa.
• Passos:
  • Enviar requisição POST /api/auth/login informando e-mail e senha corretos.
• Resultado esperado:
  • O backend deve validar o hash, retornar HTTP 200 (Success) e prover os tokens de acesso (Access e Refresh JWT).

TC-051

• < Backward: TASK-051
• Título: Validação do frontend de login e armazenamento de sessão
• Pré-condição: Estar na tela de login deslogado.
• Passos:
  • Preencher e-mail e senha e submeter o formulário.
• Resultado esperado:
  • O sistema deve realizar a chamada com sucesso, persistir os tokens de forma segura e redirecionar o usuário para a rota autenticada.

TC-052

• < Backward: TASK-052
• Título: Validação da omissão de existência de conta em falhas
• Pré-condição: Acessar o endpoint de login.
• Passos:
  • Tentar fazer login com um e-mail não cadastrado.
  • Tentar fazer login com um e-mail válido mas senha incorreta.
• Resultado esperado:
  • Ambas as requisições devem retornar a mesma mensagem de erro genérica (ex: “Credenciais inválidas” com status 401), não revelando se o erro foi no e-mail ou na senha.

TC-053

• < Backward: TASK-053
• Título: Validação de bloqueio por força bruta (account lockout) no backend
• Pré-condição: Ter uma conta válida.
• Passos:
  • Enviar propositalmente 5 requisições seguidas de login com senha incorreta para o mesmo e-mail.
  • Enviar uma 6ª requisição, desta vez com a senha correta.
• Resultado esperado:
  • O backend deve retornar HTTP 429 (Too Many Requests) ou similar na 6ª tentativa, impedindo o login até que o tempo de bloqueio expire, mesmo com credencial certa.

TC-054

• < Backward: TASK-054
• Título: Validação visual de bloqueio temporário na interface
• Pré-condição: Estar na tela de login e esgotar as tentativas (5 falhas).
• Passos:
  • Tentar realizar o 6º envio pelo formulário.
• Resultado esperado:
  • A UI deve intervir, desabilitar o botão de envio e exibir um aviso claro sobre o bloqueio temporário e o tempo restante.

TC-055

• < Backward: TASK-055
• Título: Validação da listagem de sessões ativas via API
• Pré-condição: Estar autenticado na conta em pelo menos dois navegadores ou dispositivos diferentes.
• Passos:
  • Executar requisição GET /api/auth/sessions.
• Resultado esperado:
  • O retorno deve conter uma lista identificando corretamente todos os dispositivos (através do user-agent/IP) com sessões ativas no momento.

TC-056

• < Backward: TASK-056
• Título: Validação da interface de gerenciamento de sessões
• Pré-condição: Acessar a área de Configurações de Segurança.
• Passos:
  • Navegar até a lista de sessões ativas conectadas à conta.
• Resultado esperado:
  • O frontend deve renderizar corretamente a listagem dos navegadores, destacando de forma clara a “Sessão Atual”.

TC-057

• < Backward: TASK-057
• Título: Validação do encerramento de sessão remota via API
• Pré-condição: Possuir uma sessão “A” (atual) e uma sessão “B” (remota).
• Passos:
  • Enviar requisição DELETE /api/auth/sessions/{id-da-sessao-B} a partir da sessão A.
  • Tentar acessar uma rota protegida utilizando os tokens da sessão B.
• Resultado esperado:
  • A API de exclusão deve retornar sucesso e a tentativa subsequente na sessão B deve retornar HTTP 401 (Unauthorized), confirmando a revogação do token.

TC-058

• < Backward: TASK-058
• Título: Validação do botão de revogação na interface
• Pré-condição: Estar na tela de gerenciamento de sessões com mais de um dispositivo conectado.
• Passos:
  • Clicar no botão “Encerrar Sessão” em um dispositivo que não seja o atual.
• Resultado esperado:
  • A interface deve remover a sessão da lista instantaneamente e efetivar o logout remoto.

TC-059

• < Backward: TASK-059
• Título: Validação de fluxo de reativação via API
• Pré-condição: Possuir uma conta com status “Desativada”.
• Passos:
  • Tentar login com credenciais corretas (deve retornar flag/código de conta inativa).
  • Enviar requisição POST /api/user/reactivate.
• Resultado esperado:
  • O backend deve alterar o status da conta para “Ativa” com sucesso, liberando a geração de tokens de acesso na próxima tentativa.

TC-060

• < Backward: TASK-060
• Título: Validação da interceptação visual para contas desativadas
• Pré-condição: Tentar login na interface com uma conta previamente desativada.
• Passos:
  • Submeter as credenciais de login.
  • Aceitar a confirmação no modal que questiona sobre a reativação.
• Resultado esperado:
  • O sistema não deve fazer login direto. O modal deve surgir, e após a confirmação, o sistema engata a reativação da conta e redireciona ao painel autenticado em seguida.

TC-061

• < Backward: TASK-061
• Título: Validação de registro de nova conta via API
• Pré-condição: Não estar autenticado.
• Passos:
  • Enviar requisição POST /api/auth/register com Nome, E-mail inédito e Senha.
• Resultado esperado:
  • A conta deve ser criada no banco de dados, assumindo o status “Ativa” imediatamente, retornando sucesso (201 Created).

TC-062

• < Backward: TASK-062
• Título: Validação do formulário público de inscrição na UI
• Pré-condição: Acessar a tela pública de cadastro.
• Passos:
  • Preencher os dados de Nome, E-mail válido e Senha.
  • Submeter a inscrição.
• Resultado esperado:
  • O formulário deve processar a criação de forma íntegra e redirecionar o usuário recém-criado para o onboarding ou painel inicial do sistema.

TC-063

• < Backward: TASK-063
• Título: Validação de regras e barreiras de segurança no cadastro
• Pré-condição: Estar na tela de cadastro ou via API.
• Passos:
  • Tentar cadastrar um E-mail que já existe no banco de dados.
  • Tentar cadastrar uma senha fraca (ex: “123”).
• Resultado esperado:
  • O backend/frontend devem recusar a criação, exibindo erros de unicidade de e-mail e exigência de complexidade mínima de senha.

TC-064

• < Backward: TASK-064
• Título: Validação de alteração de senha via API
• Pré-condição: Estar logado com uma conta ativa.
• Passos:
  • Enviar requisição PUT /api/user/password contendo a senha_atual correta e uma nova_senha.
• Resultado esperado:
  • O backend deve checar o hash da senha antiga, atualizar a coluna com a nova credencial de forma segura e retornar sucesso (200 OK).

TC-065

• < Backward: TASK-065
• Título: Validação do formulário de troca de senha na interface
• Pré-condição: Acessar o menu de segurança da conta.
• Passos:
  • Preencher “Senha Atual”.
  • Preencher “Nova Senha” e “Confirmar Nova Senha” (com valores idênticos).
  • Salvar alterações.
• Resultado esperado:
  • A interface deve apresentar feedbacks de validação nos campos, processar a troca e exibir uma notificação de sucesso.

TC-066

• < Backward: TASK-066
• Título: Validação de logout em cascata de sessões pós-troca de senha
• Pré-condição: Estar autenticado em dois dispositivos diferentes (A e B).
• Passos:
  • Realizar a alteração de senha a partir do dispositivo A.
  • Tentar navegar em rotas protegidas usando o dispositivo B.
• Resultado esperado:
  • O dispositivo A deve permanecer logado. O dispositivo B deve ter sua sessão invalidada automaticamente pelo servidor (HTTP 401) forçando reautenticação.

TC-067

• < Backward: TASK-067
• Título: Validação da desativação temporária da conta via API
• Pré-condição: Estar autenticado.
• Passos:
  • Enviar requisição POST /api/user/deactivate.
• Resultado esperado:
  • O banco de dados deve alterar o status do usuário para inativo, apagar (revogar) os tokens de sessão, porém, todas as tabelas de dados (cadernos, tarefas) ligadas ao usuário devem ser mantidas intactas.

TC-068

• < Backward: TASK-068
• Título: Validação visual e de fluxo na desativação temporária
• Pré-condição: Estar nas configurações da conta na interface.
• Passos:
  • Clicar no botão “Desativar minha conta”.
  • Confirmar a ação no alerta.
• Resultado esperado:
  • O usuário deve ser deslogado instantaneamente e redirecionado para a tela de login pública com uma notificação de “Conta desativada”.

TC-069

• < Backward: TASK-069
• Título: Validação de exclusão permanente em cascata via API
• Pré-condição: Possuir uma conta com diversos Cadernos, TODOs e SCHEDULEs criados.
• Passos:
  • Enviar requisição DELETE /api/user/account.
  • Fazer query direta ao banco de dados pelo ID do usuário nas tabelas de itens e cadernos.
• Resultado esperado:
  • Todos os registros atrelados à conta do usuário devem ser sumariamente apagados do banco (deleção em cascata transacional), sem sobrar nenhuma chave órfã, devolvendo sucesso HTTP (204 No Content).

TC-070

• < Backward: TASK-070
• Título: Validação do hard-lock na interface para exclusão definitiva
• Pré-condição: Acessar a zona de perigo (Danger Zone) das configurações de conta.
• Passos:
  • Acionar o botão de exclusão de conta.
  • Observar se o botão de confirmação primária está bloqueado.
  • Digitar a frase de segurança exigida (ex: “Excluir minha conta”) no input e prosseguir.
• Resultado esperado:
  • A interface jamais deve permitir a exclusão por um mero “clique acidental”, só destravando o botão de ação final quando a string de controle for digitada perfeitamente. Após o acionamento, o fluxo deve redirecionar à home pública.

TC-071

• < Backward: TASK-071
• Título: Validação de renovação de Access Token via Refresh Token válido
• Pré-condição: Possuir uma sessão ativa com Refresh Token válido e Access Token expirado.
• Passos:
  • Enviar requisição POST /api/auth/refresh com o cookie de refresh token válido.
• Resultado esperado:
  • O backend deve retornar sucesso (200) e emitir um novo Access Token via cookie, sem exigir novo login.

TC-072

• < Backward: TASK-072
• Título: Validação da exclusão de caderno com preservação de itens
• Pré-condição: Existir um caderno com ao menos 2 itens vinculados.
• Passos:
  • Enviar requisição DELETE /api/notebooks/{id}.
  • Consultar os itens anteriormente vinculados ao caderno.
• Resultado esperado:
  • O caderno deve ser removido e todos os itens devem retornar com notebookId nulo (Inbox), sem perda de dados.

TC-073

• < Backward: TASK-073
• Título: Validação do alerta de confirmação de exclusão de caderno na interface
• Pré-condição: Estar visualizando um caderno com itens na listagem.
• Passos:
  • Clicar na opção de excluir o caderno.
  • Observar o alerta exibido e confirmar a ação.
• Resultado esperado:
  • A interface deve exibir aviso informando que os itens serão movidos para a Inbox, e após a confirmação, o caderno deve sumir da listagem.

TC-074

• < Backward: TASK-074
• Título: Validação da consulta de detalhes de item via API
• Pré-condição: Existir um item TODO com sub-itens cadastrados.
• Passos:
  • Enviar requisição GET /api/items/{id}.
• Resultado esperado:
  • A resposta deve conter todas as propriedades do item e a lista completa de seus sub-itens.

TC-075

• < Backward: TASK-075
• Título: Validação de edição parcial de item e rejeição de campo incompatível
• Pré-condição: Existir um item SCHEDULE cadastrado.
• Passos:
  • Enviar requisição PATCH /api/items/{id} alterando o título (válido).
  • Enviar uma segunda requisição PATCH /api/items/{id} tentando definir o campo dueDate (inválido para SCHEDULE).
• Resultado esperado:
  • A primeira requisição deve retornar sucesso com o título atualizado; a segunda deve ser rejeitada com erro de campo incompatível com o tipo do item.

TC-076

• < Backward: TASK-076
• Título: Validação de conclusão e reversão de conclusão de TODO
• Pré-condição: Existir um item TODO ativo e não concluído.
• Passos:
  • Enviar requisição PATCH /api/items/{id}/complete com isCompleted=true.
  • Enviar nova requisição com isCompleted=false.
• Resultado esperado:
  • Após a primeira chamada, isCompleted deve ser true e status deve permanecer ATIVO; após a segunda, isCompleted deve retornar a false.

TC-077

• < Backward: TASK-077
• Título: Validação de conclusão isolada de sub-item
• Pré-condição: Existir um TODO com dois sub-itens não concluídos.
• Passos:
  • Enviar requisição PATCH /api/items/{todoId}/subitems/{subItemId} marcando apenas um dos sub-itens como concluído.
• Resultado esperado:
  • Apenas o sub-item indicado deve ser marcado como concluído; o outro sub-item e o estado de conclusão do TODO pai devem permanecer inalterados.

TC-078

• < Backward: TASK-078
• Título: Validação de remoção individual de sub-item
• Pré-condição: Existir um TODO com dois sub-itens cadastrados.
• Passos:
  • Enviar requisição DELETE /api/items/{todoId}/subitems/{subItemId} para um dos sub-itens.
• Resultado esperado:
  • O sub-item indicado deve ser removido; o TODO pai e o sub-item restante devem permanecer intactos.

TC-079

• < Backward: TASK-079
• Título: Validação de persistência de reordenação manual em lote
• Pré-condição: Existir um caderno com três itens ativos.
• Passos:
  • Enviar requisição PATCH /api/items/reorder informando o notebookId e a nova ordem completa dos três IDs.
  • Consultar a listagem do caderno em seguida.
• Resultado esperado:
  • A listagem deve refletir exatamente a nova ordem enviada.

TC-080

• < Backward: TASK-080
• Título: Validação do interceptor de renovação silenciosa no frontend
• Pré-condição: Estar navegando no sistema com Access Token prestes a expirar e Refresh Token válido.
• Passos:
  • Aguardar a expiração do Access Token durante o uso ativo da aplicação.
  • Realizar uma ação que dispare uma chamada protegida à API.
• Resultado esperado:
  • A aplicação deve renovar o Access Token automaticamente em segundo plano e completar a ação solicitada sem exibir tela de login.

TC-081

• < Backward: TASK-081
• Título: Validação de revogação em massa preservando a sessão corrente
• Pré-condição: Estar autenticado em três dispositivos diferentes (A, B, C).
• Passos:
  • A partir do dispositivo A, enviar requisição DELETE /api/auth/sessions.
  • Tentar acessar uma rota protegida a partir dos dispositivos B e C, e depois a partir do dispositivo A.
• Resultado esperado:
  • As sessões B e C devem retornar HTTP 401 (revogadas); a sessão A deve continuar válida.

TC-082

• < Backward: TASK-082
• Título: Validação da consulta de perfil do usuário autenticado
• Pré-condição: Estar autenticado com uma conta válida.
• Passos:
  • Enviar requisição GET /api/user/me.
• Resultado esperado:
  • A resposta deve conter nome, e-mail e status da conta correspondentes ao usuário autenticado.

TC-083

• < Backward: TASK-083
• Título: Validação do preenchimento automático do formulário de Configurações
• Pré-condição: Acessar a tela de Configurações da conta.
• Passos:
  • Observar os campos do formulário ao carregar a tela, antes de qualquer edição.
• Resultado esperado:
  • Os campos de nome e e-mail devem estar previamente preenchidos com os dados atuais do usuário.

TC-084

• < Backward: TASK-084
• Título: Validação do modal de detalhes de item na interface
• Pré-condição: Existir um item TODO com sub-itens e um item SCHEDULE cadastrados.
• Passos:
  • Abrir o modal de detalhes do item TODO.
  • Abrir o modal de detalhes do item SCHEDULE.
• Resultado esperado:
  • O modal do TODO deve exibir a seção de sub-itens; o modal do SCHEDULE não deve exibir essa seção.

TC-085

• < Backward: TASK-085
• Título: Validação do formulário de edição de item conforme o tipo
• Pré-condição: Abrir o formulário de edição para um item TODO e, em seguida, para um item SCHEDULE.
• Passos:
  • Verificar os campos exibidos em cada formulário.
• Resultado esperado:
  • O formulário do TODO deve exibir data limite; o formulário do SCHEDULE não deve exibir esse campo, exibindo apenas horários de início/término.

TC-086

• < Backward: TASK-086
• Título: Validação do checkbox de conclusão na listagem
• Pré-condição: Visualizar um TODO ativo na Todo List.
• Passos:
  • Clicar no checkbox de conclusão do item.
• Resultado esperado:
  • O item deve ser marcado visualmente como concluído imediatamente, sem recarregar a página.

TC-087

• < Backward: TASK-087
• Título: Validação do checkbox de conclusão de sub-item na interface
• Pré-condição: Visualizar um TODO com sub-itens não concluídos.
• Passos:
  • Marcar um dos sub-itens como concluído pela interface.
• Resultado esperado:
  • Apenas o sub-item marcado deve mudar de estado visualmente; o TODO pai não deve ser afetado.

TC-088

• < Backward: TASK-088
• Título: Validação do botão de remoção individual de sub-item na interface
• Pré-condição: Visualizar um TODO com dois sub-itens.
• Passos:
  • Clicar no botão de remoção de um dos sub-itens.
• Resultado esperado:
  • O sub-item selecionado deve desaparecer da lista imediatamente; o outro sub-item deve permanecer visível.

TC-089

• < Backward: TASK-089
• Título: Validação do botão “Encerrar todas as outras sessões” na interface
• Pré-condição: Estar na tela de sessões ativas com múltiplos dispositivos conectados.
• Passos:
  • Clicar no botão de encerrar todas as outras sessões.
• Resultado esperado:
  • A listagem deve atualizar-se exibindo apenas a sessão corrente.

TC-090

• < Backward: TASK-090
• Título: Validação da persistência da ordem manual após recarregamento
• Pré-condição: Estar na Todo List no modo de ordenação Manual.
• Passos:
  • Arrastar um item para uma nova posição.
  • Recarregar a página.
• Resultado esperado:
  • O item deve permanecer na posição definida manualmente após o recarregamento.