Abbiamo diversi moduli che gestiscono varie parti di un messaggio in arrivo. Ogni modulo esegue alcuni lavori indipendenti sul messaggio (ad esempio, scrive sul DB, invia al client) e tutti i moduli vengono richiamati ogni volta che arriva un messaggio.
Inoltre, abbiamo una certa logica di filtraggio che ha deciso se gestire effettivamente o meno un messaggio in arrivo (ad esempio, se il messaggio è valido o meno).
Nell'attuale architettura di test disponiamo di una suite di test per modulo che verifica solo la sua funzionalità - invia un messaggio e vede che viene intrapresa l'azione corretta.
Tuttavia, il test della logica di filtraggio non viene gestito correttamente. Da un lato, impatta su ciascuno dei moduli, quindi sarebbe logico posizionare i test di filtraggio per ogni modulo (fondamentalmente eseguendo i test di ciascun modulo con il messaggio consentito e con il messaggio bloccato). D'altra parte, si tratta di una duplicazione degli sforzi poiché il codice per verificare "messaggio consentito" e "messaggio bloccato" è lo stesso, è solo ciò che viene testato è diverso (ad esempio, se il messaggio viene scritto nel DB o no, se il messaggio viene inviato al client o no, ecc.).
Attualmente sto estraendo il codice comune per testare la logica di filtraggio e quindi facendo riferimento a esso nelle suite di test del modulo, ma ancora non mi sembra l'approccio migliore per questo.
L'applicazione è scritta in Erlang e il framework di test è Erlang's Common Tests.
Modifica: le suite di test attualmente implementate non sono puramente test unitari. Piuttosto, si tratta di una combinazione di test di sistema (in realtà collegando un client fittizio e l'invio di un messaggio attraverso il server in fase di test) e test di verifica diretta dell'unità (utilizzando l'interfaccia di nodo semplice Erlang per chiamare le funzioni interne sul server) .