Edizione Corso Test Driven Development Presso Azienda Settore Finance

Lo Studio Ingegneria Demichelis ha completato l’erogazione di un’altra edizione del corso TDD presso un’importante azienda operante nel settore finance. I numerosi partecipanti hanno dato vita ad un’edizione del corso molto attiva dove con svariati esempi sono stati trasmessi i fondamenti di Test Driven Development con Java.

Corso Test Driven Development Settembre / Ottobre 2015
Corso Test Driven Development Settembre / Ottobre 2015

Indirect Input & Output in Unit Testing

Un test unitario definisce un particolare scenario di funzionamento di un unica “unità” che può essere definita come: system under test (SUT), object under test o unit under test, proprio per sottolineare la focalizzazione di cui è oggetto nel test.

 

Per eseguire il SUT nello scenario desiderato è necessario fornirgli un input, cioè l’insieme di informazioni che stimolano la funzionalità in via di definizione attraverso il test unitario. l’output comprende tutte le informazioni restituite dal SUT a seguito alla stimolazione, e su queste sono espressi i vincoli e le attese del test unitario.

 

Raramente, però, un oggetto può portare a termine il proprio compito in perfetto isolamento; il più delle volte esso necessita di collaboratori. L’output dei collaboratori rappresenta per il SUT una forma di input, meglio descritto come input indiretto. Si noti che a parità di input, l’output del SUT dipenderà dall’input indiretto proveniente dai collaboratori.

 

Un test unitario dovrebbe anche definire quali siano le ripercussioni il SUT deve avere sui collaboratori nello scenario eseguito. Tali ripercussioni sono l’indirect output del SUT e possono anch’esse essere oggetto di verifica da parte del test unitario.

indirect_input_output

Si immagini ad una comune applicazione web che permetta ai nuovi utenti di registrarsi fornendo email e password. Se la registrazione va a buon fine, il nuovo utente riceve all’indirizzo di posta dichiarato una email di conferma.

Il processo di registrazione è gestito da un oggetto di tipo RegistrationController che utilizza due collaboratori:

  • un’istanza di UserRepository, servizio che incapsula l’accesso al database degli utenti permettendo di crearne di nuovi e di verificare se un’email sia già utilizzata;
  • un’istanza di Notifier, servizio che permette di inviare email di conferma.

Si ipotizzi di impostare il test unitario che specifichi il comportamento di RegistrationController in caso di registrazione di un nuovo utente con username ancora non utilizzato. Sommariamente lo scenario che si vuole sia verificato dal SUT è il seguente:

  1. Dati…
    1. uno UserRepository (collaborator) che ancora non ha censito alcun utente (e che quindi fornirà un indirect input rappresentante l’assenza di alcun utente),
    2. un Notifier (collaborator),
    3. un RegistrationController (SUT) che usa i precedenti oggetti come collaborator,
  2. quando…
    1. si invoca il metodo newRegistration() di RegistrationController fornendo un’email e una password (stimolazione del SUT)
  3. deve accadere che…
    1. newRegistration() restituisca la stringa “registration_ok” (verifica dell’output)
    2. RegistrationController invochi il metodo sendConfirmationEmail() di Notifier, passando come email la stessa usata per registrarsi (verifica dell’indirect output)

 

Ovviamente questo è solo uno dei vari Test Unitari che andrebbero definiti. Lo scopo in questo caso è tuttavia quello di focalizzare l’attenzione su due punti.

  1. l’output del SUT, verificato al passo 3a) dipende anche dall’indirect input fornito dal collaboratore definito al punto 1a).
  2. Non solo un test unitario deve verificare l’output del SUT, ma anche le ripercussioni che il SUT ha sugli altri collaboratori.

 

Sia impostare l’indirect input che verificare l’indirect output sono due attività che possono essere realizzate seguendo diversi stili ed utilizzando diverse tecnologie, ma questo è materiale per un altro post.
Questi e altri concetti, esempi ed esercizi sono presentati in dettaglio nel corso Test Driven Development organizzato dallo Studio Ingegneria Demichelis presso la tua Azienda, sul sito dedicato trovi tutte le informazioni, ma per qualsiasi approfondimento contattaci pure.

Performance Automated Test as Comparison Test

Lately I was thinking how to teach to use JUnit to execute some performance test. I gave a try to both p-unit and JPerf. Apart the fact they do not seem to be actively maintained any more, they suffered, in my point of view, from a dependency on the system clock. This sounded very strange to me, because measuring performances with the system clock gives results that are hardly generalized to other machines.

So, what could be a solution ? Just use two codes that perform the same task. One is the reference, while the other is the one performances are measured related to the reference.

If you’re interested I would point you to the very detailed Francesco’s post about the matter.

 

Corso Test Driven Development a Milano

Aggiornamento: purtroppo il corso non è stato organizzato a causa dell’insufficiente numero di iscritti.

Mercoledi 16 Maggio terrò un corso sull’utilizzo di Unit Test e sull’adozione di Test Driven Development presso la Fondazione dell’Ordine degli Ingegneri della Provincia di Milano.

La giornata sarà focalizzata su tre argomenti principali:

  • l’analisi di costi e benefici dell’adozione del Test Driven Development basata sullo studio di casi ed esperimenti descritti in letteratura;
  • l’illustrazione delle idee alla base del Test Driven Development e una serie di tutorial che mostrano l’utilizzo di alcuni strumenti standard nello sviluppo di una applicazione;
  • come il Test Driven Development si integri in un contesto aziendale esistente e quali possano essere le criticità nella sua adozione.

La locandina contiene il programma dettagliato e le informazioni sul costo del corso.