PDVMonitor.Tests é o projeto de testes unitários para a aplicação PDVMonitor, um sistema de monitoramento de ponto de venda (PDV). O projeto foi desenvolvido para garantir a qualidade, confiabilidade e manutenibilidade da camada de serviços da aplicação via testes automatizados abrangentes.

Stack Tecnológica

• .NET 6 e .NET Core 3.1 (suporte multi-targeting)
• C# 10.0
• xUnit - Framework de testes principal
• Moq - Framework para criação de mocks
• AutoMapper - Mapeamento de objetos para testes
• TNF (Totvs .NET Framework) - Integração com framework corporativo
• Microsoft.Extensions.DependencyInjection - Injeção de dependência

Arquitetura do Projeto

O projeto segue uma estrutura organizada por domínios de negócio

Propósito

Valida o comportamento completo do serviço de brindes (BrindeService), garantindo que todas as operações CRUD (Create, Read, Update, Delete) funcionem corretamente e que as regras de negócio sejam aplicadas adequadamente.

Configuração da Classe

Dependências Mockadas

• INotificationHandler: Gerencia notificações e validações de negócio
• Configurado através do NotificationHandlerMockHelper.Create()
• IBrindeRepository: Camada de acesso a dados para brindes
• Mock configurado individualmente por teste
• ServiceProvider: Provedor de serviços para AutoMapper
• Configurado através do AutoMapperTestHelper.CreateBrindeServiceProvider()

 Características Específicas dos Testes

• Validação de DTO Vazio
• • Testa cenário onde nenhum campo é preenchido
  • Garante que validações básicas funcionem

• Validação de Regras de Negócio
• • Testa quantidade de estoque negativa
  • Valida que regras de domínio são aplicadas

• Teste de Sucesso
  • Configura mock do repositório para retornar entidade
  • Verifica mapeamento correto entre DTO e entidade
  • Confirma que todos os campos são preservados

• Testes de Consulta
  • Busca por ID específico
  • Listagem completa com filtros
  • Verificação de integridade dos dados retornados

Padrões de Teste Implementados

• Padrão Arrange-Act-Assert (AAA)

Todos os testes seguem a estrutura padrão:

• Nomenclatura Padronizada
  • Estrutura do Nome: {Método}_{Should}{Comportamento}_{When}{Condição}
  • Exemplo: Adicionar_ShouldReturnNull_WhenDtoIsInvalid
  • Benefícios: Clareza sobre cenário testado e resultado esperado

• Isolamento de Testes
  • Cada teste é independente
  • Mocks são configurados especificamente para cada cenário
  • Não há dependências entre testes

Classes Helper Referenciadas

NotificationHandlerMockHelper

Propósito: Centraliza a criação de mocks para INotificationHandler

Benefícios:

• Configuração consistente entre testes
• Redução de código duplicado
• Padronização de comportamentos de notificação

AutoMapperTestHelper

Propósito: Configura o ServiceProvider com mapeamentos necessários para testes

Benefícios:

• Configuração isolada do AutoMapper para testes
• Ambiente controlado para mapeamentos
• Evita dependências externas

Captura de tela mostrando que os passos citados acima, funcionaram corretamente.