2016-07-10 18 views
5

Ho appena iniziato a testare MediatR per pulire i nostri pesanti web controller coinvolti. Implementare la funzionalità da sola non è affatto difficile, ma faccio fatica a sperimentare.Come testare con MediatR

Ho iniziato con un metodo di controllo per l'annullamento di un ordine.

Quando un ordine viene annullato, dove abbiamo

  • L'impostazione di un flag 'annullata' sui dati nel database
  • registrazione che ha annullato l'incontro in un registro di controllo
  • invio di una notifica via e-mail ad un certo supervisore.

Tutto questo è stato attivato all'interno del metodo del controller, rendendo il controllore dipendente da diversi servizi diversi. Durante il test, abbiamo dovuto prendere in giro ogni parte per isolare il comportamento che volevamo testare.

Il modo in cui l'ho implementato con MediatR era di emettere un valore CancelOrder -query dal metodo del controller. Ho quindi creato uno CancelOrderHandler responsabile della memorizzazione della bandiera "cancellata".

Utilizzando un'applicazione personalizzata MediatorPipeline, emetto un OrderCancelled -notifica se il CancelOrderHandler non genera eccezioni.

Ho due gestori per questa notifica: OrderCancelledAuditLogHandler e OrderCancelledNotificationHandler. Il primo si occuperà del registro di controllo, mentre il secondo invierà le notifiche.

Ogni gestore è facile da testare. Ma come posso testare che tutto 'combacia insieme'? Voglio assicurarmi che quando un ordine viene cancellato, il registro di controllo e la notifica siano effettivamente presi in considerazione. Tutti i gestori fanno cose che non desidero davvero durante l'esecuzione del test (scritture di database e invio di e-mail) e non sono entusiasta di un completo test di integrazione end-to-end.

Qualche idea?

+0

Potresti postare un po 'di codice - dei tuoi gestori, e come spedisci, ecc ...? – Alex

+0

Non c'è niente di interessante lì, penso ... Ho seguito gli schemi da [post sul blog di Bogards] (https://lostechies.com/jimmybogard/2014/09/09/tackling-cross-cutting-concerns-with-a -mediator-pipeline /) e utilizza il contenitore IoC per decorare tutti gli 'IRequestHandler <>' per inviare eventi post. – Vegar

risposta

1

Mi sto occupando dello stesso problema. Sono propenso a testare ciascuno dei componenti che sono usati singolarmente nell'handler, quindi a crearlo, in qualche modo non ancora sicuro al 100%, dove collaudo le richieste e i gestori in modo simile a come Bogard ha fatto i test per il progetto Mediatr su GitHub

+0

Sto pensando di creare un 'message graph' usando speciali 'post-notification handler 'e qualche tipo di' message relay'. Quindi un gestore può essere contrassegnato come un gestore di notifiche di post per un messaggio (come un gestore di eventi successivi) e un tale gestore può essere implementato come un gestore di 'send another message'. Spero di essere in grado di costruire una "catena" di gestori in base alle classi trovate da ioc, e quindi di asserirle. Penso che sarà meglio che effettivamente eseguendo la catena. – Vegar