Il worskshop per IAD18 su un modo diverso di testare gli eventi tenuto da me ed Alberto Acerbis

1. UN MICROSERVIZIO CQRS CON
EVENT SOURCING
Dallo sviluppo al testing non convenzionale

2. REPOSITORY (BRANCH: MASTER)
https://github.com/Iridio/
/CQRS-ES_testing_workshop

3. PROGRAMMA
 Introduzione
 Event storming
 Allestiamo il progetto
 Pausa
 Scriviamo i test
 Q&A

4. INTRODUZIONE

5. CQRS+ES
https://benwilcock.wordpress.com

6. EVENT STORMING

7. ALLESTIAMO IL PROGETTO

8. PAUSA

9. SCRIVIAMO I TEST

10. ESERCIZIO 1 – 50 MINUTI
Quando un utente del nostro sito inizia il processo di acquisto, il sistema blocca per 15 minuti i posti selezionati.
In questo esercizio dovrai scrivere il test ed il relativo codice per bloccare temporaneamente i posti selezionati
dall'utente. (Comando ReserveSeats)
Come spiegato, ricorda che i comandi sono imperativi, mentre gli eventi sono al passato in quanto è qualcosa che è
successo.
Ricorda inoltre, che il test parte da una lista di eventi (Given()) che rappresentano lo stato iniziale dell'aggregato, che è il
comando (When() ed OnHandler()) a far scatenare il tutto ed, infine, che devi specificare qual è o quali sono gli eventi che
ci aspettiamo siano creati dall'aggregato.
Si è deciso che l'aggregato espone la lista dei posti composti da numero, riga e stato. Lo stato non viene passato nel
comando in quanto superfluo, è il comando stesso che ci dice cosa fare con quei posti, pertanto lo stato sarà il nostro
aggregato ad impostarlo, proprio come il comando che abbiamo visto insieme.
Per incrociare i posti liberi con quelli occupati temporaneamente, puoi anche usare il comando Intersect di Linq oltre al
classico for/foreach
var seatsToCheck = seats.Intersect(seatsToReserve.ToEntity(SeatState.Free));
La classe CommandSpecification espone già un repository con i suoi metodi collegati ad un event store in memoria,
pertanto non dovrai fare nulla se non invocare Repository.GetById all'interno del tuo test.

11. ESERCIZIO 2 – 40 MINUTI
Se per qualche motivo ci dovesse arrivare un comando che cerca di riservare dei posti già occupati, dovremo emettere
un'eccezione e non generare alcun evento.
In realtà potremmo anche emettere un evento che avvisa che non si sono potuti occupare i posti, se invece la gestione dei
nostri comandi fosse sincrona l'eccezione sarebbe sufficiente.
Lo scopo dell'esercizio però è solo testare un'eccezione pertanto affronteremo questi discorsi davanti ad una birra, ma non
adesso :)
In questo esercizio dovrai scrivere un test che verifichi non vengano emessi eventi, ma bensì un eccezione.
Ricorda quindi di creare una situazione (Given()) ed un comando (When() ed OnHanlder()) che scatenino l'eccezione da
parte dell'aggregato.
La classe CommandSpecification espone una proprietà "ExpectedException" che non devi far altro che valorizzare nel
costruttore del tuo test.
Per esempio: ExpectedException = new Exception("la mia eccezione");

12. ESERCIZIO 3 – 30 MINUTI
Quando l'utente termina il pagamento dei posti che desidera, il nostro sistema dovrà trasformare lo stato dei posti
"reserved" in "booked".
Come spiegato ricorda che i comandi sono imperativi, mentre gli eventi sono al passato in quanto è qualcosa che è
successo.
In questo esercizio dovrai scrivere tutta la gestione scatenata dal comando "BookSeats"

13. QUESTIONS?

14. BIBLIOGRAFIA
 Domain-Driven Design: Tackling Complexity in the Heart of Software (E. Evans)
https://www.amazon.it/Domain-Driven-Design-Tackling-Complexity-Software-ebook/dp/B00794TAUG
 Implementing Domain-Driven Design (V. Vernon)
https://www.amazon.it/Implementing-Domain-Driven-Design-Vaughn-Vernon-ebook/dp/B00BCLEBN8/
 Introducing Event storming (A.Brandolini)
https://leanpub.com/introducing_eventstorming
 REST in Practice: Hypermedia and Systems Architecture (J.Webber)
https://www.amazon.it/REST-Practice-Hypermedia-Systems-Architecture/dp/0596805829
 Enterprise Integration Patterns (G. Hohpe)
https://www.amazon.it/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683/