Ci sono troppi asserti in questo test unitario?

Question

Ci sono troppi asserimenti in questo test?

[Fact] 
public void Send_sends_an_email_message() { 
    using (var server = new MockSmtpServer()) { 
     server.Start(); 
     using (var client = new EmailClient("localhost")) { 
      string from = "john.doe@example.com"; 
      IEnumerable<string> to = new[] { "jane.doe@example.com" }; 
      string subject = "Test"; 
      string body = "Test."; 
      client.Send(from, to, subject, body); 
      var session = server.Sessions.FirstOrDefault(); 
      Assert.NotNull(session); 
      var message = session.Messages.FirstOrDefault(); 
      Assert.NotNull(message); 
      Assert.NotNull(message.From); 
      Assert.Equal(message.From.Address, "john.doe@example.com"); 
      Assert.NotNull(message.To); 
      var recipient = message.To.FirstOrDefault(); 
      Assert.NotNull(recipient); 
      Assert.Equal(recipient.Address, "jane.doe@example.com"); 
      Assert.Equal(message.Subject, "Test"); 
      Assert.Equal(message.Body, "Test."); 
     } 
    } 
} 

Non penso che questo codice richieda alcuna spiegazione, ma se lo fa fammi sapere.

Answer 1

Cerco di mantenere i miei UnitTests abbastanza piccoli e di testare una cosa alla volta. Quindi probabilmente effettuerò test di parti distinte in test separati, ad es.

• sendWillSendAnEmail,
• fromContainsSenderAddress,
• toContainsRecipientAddress,
• mailBodyContainsMailMessage,
• mailContainsSubject

Answer 2

In generale, più asserzioni, meglio è. Un errore comune nei test unitari non è abbastanza esplicito.

Il test è molto esplicito e leggibile. Mi piacciono particolarmente le affermazioni su null. È una buona pratica perché rende l'interpretazione di un test fallito estremamente semplice.

L'unico modo in cui si possono avere troppe asserzioni è se si asserisce la stessa cosa più di una volta, cosa che non si sta facendo.

Answer 3

non vedo alcun problema particolare con il vostro afferma, ma se si vuole ripulire il codice, si potrebbe cambiare

var session = server.Sessions.FirstOrDefault(); 
Assert.NotNull(session); 

in

var session = server.Sessions.First(); 

First() un'eccezione comunque, in modo da semplicemente cambiando il tuo codice ottieni il vantaggio che l'asserzione ti avrebbe portato senza tanto codice. Ci sono altri posti in cui puoi fare cambiamenti simili.

Ma come regola generale, non dare nulla per scontato in unit test - e questo significa un sacco di asserzioni!

Answer 4

Dipende dagli standard a cui si sta aderendo, ma in genere direi di sì, nel test ci sono state troppe affermazioni.

Molte persone sostengono che un singolo test dovrebbe avere un'unica affermazione; Penso che possa essere un po 'eccessivo, ma credo certamente che sia appropriato avere un test unitario per un singolo "pezzo" di funzionalità; sei dappertutto con le tue affermazioni. Il test è troppo grande; suddividerlo in diversi test.

Answer 5

Penso che la domanda è, fanno le assert() d valori cambiano in modo indipendente? Se cambiano in modo indipendente, devono essere testati in diversi test che variano le condizioni relative a ciascuna affermazione.

Se tuttavia si dispone di un singolo codep che genera un'e-mail con tutti quei campi, è opportuno testare tutte le cose in un test.

Ora il test è piuttosto difficile da leggere. Potresti voler avvolgere quegli asserti in un metodo di supporto descrittivo. Non mi preoccuperei di questo finché non trovo che lo stesso metodo di supporto potrebbe essere utile da qualche altra parte.

Answer 6

Penso che sia troppo grande.

Quando si dispone di una serie di test più piccoli, è possibile ottenere la "localizzazione dei difetti": è sufficiente eseguire tutti i test per vedere esattamente dove si trova un problema. Con il maggior numero di affermazioni che hai attualmente (e non asserire messaggi), probabilmente dovresti avviare un debugger per scoprirlo. Ricorda che probabilmente finirai per avere centinaia se non migliaia di test, e se un gruppo di loro non funziona, non devi fare il debug di ognuno per capire perché.

Inoltre, qualsiasi affermazione che fallisce all'inizio del test significa che le asserzioni successive non vengono eseguite. Quando sono separati in singoli test, ogni assert viene controllato. Questo è una sorta di compromesso; molti di questi sono probabilmente correlati e falliranno allo stesso tempo, quindi avrai cinque test rossi invece di uno. Ma io lavoro dal presupposto che maggiori informazioni sono migliori, quindi preferirei avere quei cinque test e sapere che tutti e cinque gli asseriti falliscono.

Answer 7

Le tue numerose affermazioni assert sono un indicatore di quanta logica hai nei test unitari. Dovrai mantenere i tuoi test unitari come un normale codice. È meglio dedicare del tempo alla programmazione difensiva e alla programmazione per contratto piuttosto che alle prove unitarie del codice.

Answer 8

Forse è possibile creare una nuova classe di e-mail che accetta tutti quei parametri nel suo costruttore predefinito.

E quindi è possibile generare un'eccezione nel caso in cui l'utente passi un parametro non valido.

E nel tuo test di unità

Send_sends_an_email_message

è possibile aggiungere l'sostiene che controlla uguaglianze solo che invece di controllare contro NULL.

Forse puoi creare 2 email in un test e fare l'uguaglianza per entrambe le istanze.

Answer 9

Sì, hai troppe affermazioni nel tuo codice! Inoltre, la dichiarazione di affermazione dovrebbe essere solo una per metodo di prova. L'uso di molti asseriti può essere l'odore del codice che stai testando più di una cosa. Inoltre, c'è la possibilità che qualcuno possa aggiungere nuove asserzioni al test invece di scriverne un altro. E come puoi capire in che modo il tuo altro afferma completato quando il primo fallisce?

Forse potresti trovato interessante questo post: https://timetocode.wordpress.com/2016/06/01/zen-of-unit-testing/