Adicionar evento de auditoria de e-mail na classe ConsumePublishedRecourseEmails

[Junior-Shyko]

Contexto

A classe ConsumePublishedRecourseEmails é um worker responsável por consumir a fila 'plugin_published_recourses' do RabbitMQ e disparar e-mails relacionados aos recursos publicados. Atualmente, não há um registro de auditoria no banco de dados para comprovar o envio desses e-mails. É essencial implementar um mecanismo de evento após o envio bem-sucedido de cada e-mail para registrar essa ação, garantindo a rastreabilidade e a comprovação dos comunicados relacionados aos recursos.

Objetivo

Como um Programador (Dev)
Quero implementar o disparo de um evento específico após o envio bem-sucedido de e-mail dentro da classe ConsumePublishedRecourseEmails
Para permitir que a auditoria de e-mails seja registrada no banco de dados, fornecendo comprovação e rastreabilidade dos comunicados relacionados aos recursos.

Escopo

• Identificar o ponto exato dentro da classe ConsumePublishedRecourseEmails onde o e-mail para o proponente/agente é disparado.
• Implementar o disparo de um novo evento customizado (reutilizando, se possível, o EmailSentEvent ou similar) após a confirmação do envio do e-mail.
• O evento disparado deve conter informações essenciais para a auditoria (ex: ID do recurso, tipo de e-mail, timestamp).
• Garantir que o Listener configurado para o evento registre a auditoria no banco de dados.

Fora de Escopo

• Desenvolvimento de uma nova tabela ou modelo de banco de dados para armazenar a auditoria (assumimos que o Listener utilizará uma estrutura de dados existente).
• Alterações na configuração do RabbitMQ, fila ou Listener da aplicação.
• Implementação da lógica de tratamento de falhas de e-mail (ex: dead letter queues ou reenvio).

Critérios de Aceitação (Gherkin/Cucumber)

1. Disparo de Evento em Caso de Sucesso

Dado que a classe ConsumePublishedRecourseEmails consumiu uma mensagem do RabbitMQ
E o envio de e-mail para o proponente/agente relacionado ao recurso foi concluído com sucesso
Quando a linha de código subsequente é alcançada
Então o evento de auditoria de e-mail deve ser disparado
E o evento deve carregar os dados necessários para o registro (ID do recurso, etc.).

2. Gravação da Auditoria (Comportamento do Listener)

Dado que o evento de auditoria de e-mail foi disparado pelo worker
Quando o Listener configurado para este evento é acionado
Então um novo registro de auditoria deve ser criado no banco de dados
E este registro deve refletir o recurso e o timestamp do envio.

3. Teste Unitário da Implementação do Evento

Dado que um teste unitário está sendo executado contra a classe ConsumePublishedRecourseEmails
Quando o método de processamento que envia o e-mail simulado é chamado
Então o teste deve verificar se o evento de auditoria de e-mail foi disparado corretamente
E os dados passados ao evento devem ser validados.

Observações

• O mecanismo de evento/listener deve ser assíncrono (se possível) para não atrasar o consumo de outras mensagens na fila do RabbitMQ.
• É crucial garantir que o teste unitário utilize Mocks para simular o recebimento da mensagem do RabbitMQ e o sucesso do envio de e-mail.