Community give back

Uso questo termine altisonante per raccontare quello che stiamo facendo, sempre di più in ideato, forse per la mia partecipazione attiva al GrUSP, forse perché, in realtà, ci piace davvero lavorare in un ecosistema più sano e ci vogliamo impegnare seriamente a crearlo.

Negli anni abbiamo sempre partecipato a conferenze ed eventi che ci vedevano protagonisti con interventi, workshop e talk. Solo nell’ultimo mese abbiamo partecipato allo SMAU, con 2 talk al SymfonyDay e durante novembre saremo presenti al Codemotion di Milano ed all’AgileDay con un talk ed un posto ad una tavola rotonda e la scaletta per il 2017 è già piena.

Abbiamo però deciso di lasciare la nostra zona di conforto e ci siamo spinti ad operare anche sul fronte della formazione strutturata, grazie anche al supporto della Tag Innovation School, diventando, grazie al lavoro di Carla e Vittorio, il partner tecnologico del CodeMaster di Milano (e prossimamente Roma) ed aiutando nuove leve a comprendere le basi di questa professione.

Ma non ci siamo fermati qui.

Ognuno di noi nel suo piccolo sta portando in giro e raccontando quella che è la nostra visione di azienda, lavoro e collaborazione sana. Da Pietro e la sua lecture a degli studenti delle medie a Milano, a Simone (e me) con due interventi presso la Facoltà di Scienza e Tecnologie Informatiche di Cesena.

Diamo qualcosa indietro alla community facendo si che anche le prossime generazioni conoscano i corretti valori e le buone pratiche per poter diventare grandi professionisti.

 

CQRS ed Event Sourcing: Il nostro primo progetto andato in produzione – Parte 3 Testing

In ideato crediamo molto nella qualità del codice e di conseguenza nei test automatici. In Soisy non abbiamo fatto eccezione e come vedremo a breve, grazie alle componenti di Broadway, fare test unitari sulla nostra logica di business è veramente facile.

Anche in questo caso andremo ad implementare due tipologie di test unitari rispettivamente per la scrittura e per la lettura.

Come testare un comando (e quindi controllare che il giusto evento verrà salvato)

Negli articoli precedenti abbiamo visto come possiamo approvare un prestito ovvero:  “dato che un prestito è stato richiesto, quando viene inviato il comando ApproveLoan allora dovrà essere salvato un evento LoanApproved”.

Con broadway possiamo implementare il test proprio come descritto sopra:

Broadway implementa la classe Scenario che espone un’interfaccia fluente con in metodi given, when, then e internamente utilizza un InMemory repository come mock dell’event store. Cosi facendo i test sono isolati dal database e molto veloci.

Given prende come parametro un array di eventi che verranno applicati all’aggregato Loan il quale verrà quindi ricostruito e portato in un determinato stato, che per noi è quello che assume dopo che l’utente ha richiesto un prestito.

When prende un comando che verrà inviato all’aggregato Loan. In sostanza verrà chiamato il metodo Loan::approve il quale applicherà l’evento LoanApproved con lo stato desiderato ovvero con $status == ‘OK’ dato che stiamo testando un approvazione.

Then è il metodo che effettua l’asserzione di uguaglianza tra il vero evento applicato (actual) e l’evento LoanApproved che gli stiamo passando come parametro (expected).

Stiamo quindi testando che dato un comando verrà salvato l’evento che ci aspettiamo, con lo stato voluto.

Come testare la proiezione (e quindi che il giusto read model sia salvato)

Applichiamo gli stessi concetti per il testing del read model ovvero: “dato che è stato richiesto un prestito, quando il prestito verrà approvato allora il read model verrà correttamente aggiornato e salvato”.

Come potete vedere il gioco è sempre lo stesso solo che questa volta, la when prende un evento dato che il read model verrà modificato solo dopo che l’evento è accaduto. Il then si assicura che il read model generato dal codice di produzione sia quello che ci aspettiamo ovvero $expecetdLoan.

Broadway mette a disposizione nel repository git degli esempi di utilizzo.
Nel prossimo post vedremo come implementare un’api in cqrs + event sourcing.

Test funzionali: lenti, accoppiati ma utili

paratest 2

Mi trovo spesso a sviluppare applicazioni web tramite l’utilizzo di framework full-stack come Symfony o Zend. Questi strumenti, uniti alla natura delle applicazioni stesse, mi portano a scrivere molti test funzionali che a loro volta si portano dietro sia aspetti positivi che negativi. Qui vorrei esplorare quali sono questi aspetti e quando è realmente importante fare test funzionali.

Prima di tutto capiamo bene di che tipo di test stiamo parlando. Tramite il pattern AAA potremo descrivere un test funzionale in questa maniera:

  • Arrange: prepariamo fixtures necessarie a portare la nostra applicazione in un determinato stato iniziale. Tipicamente le fixtures sono dati da caricare su DB, stub di servizi, ecc.
  • Act: eseguiamo il codice di produzione che vogliamo testare. Ad esempio facciamo una request all’uri che indentifica la pagina che vogliamo testare.
  • Assert: controlliamo che il risultato ottenuto cioè che la response sia quella che ci aspettiamo. Questo viene fatto controllando la response e/o il DOM.

(altro…)