Con i test unitari il dominio è piuttosto piccolo, quindi è facile. Ho usato lo schema methodName_conditions_result() di Osherove e l'ho trovato molto chiaro.
Ma con i test di integrazione ho l'impressione che sarebbe un nome molto lungo e che cosa metto al posto di methodName ? Come denominare le classi di test di integrazione?
Esempi reali di nomi di test di integrazione sono i benvenuti. Spero che le risposte mi aiutino anche a capire meglio questi test.
Ho un approccio leggermente diverso con i test di unità e integrazione. Provo a nominarli il più possibile in base alle funzionalità. Poi, quando passano tutti i test, puoi vedere un elenco di tutte le funzioni che funzionano e non funzionano.
Non è sempre pragmatico nominare i test in questo modo, ma può essere molto utile soprattutto dopo aver letto centinaia di test di unità e di integrazione. Il nome di classe onnicomprensivo che contiene questi metodi dovrebbe anche essere indicativo delle funzionalità testate. Aiuterà con l'organizzazione.
Suggerirei anche di nominare qualsiasi unit test per correggere i bug con un prefisso univoco come bugfix1002 per dimostrare che il bug è stato corretto.
Questo è stato scritto per aiutare con i test unitari, ma forse scoprirai che le stesse regole si applicano (più o meno) ai test di integrazione:
Controlla Sette passaggi !
La mia preferenza è che qualunque cosa tu lo chiami, è in realtà il nome della suite di test (nome della fixture sulla nostra scheda), l'effetto che stai controllando e il messaggio di asserzione che deve distinguersi e rendere chiara la causa dell'errore . Se trovi che è più facile con la denominazione di Asherove, allora lo approvo con tutto il cuore. Ma forse il trucco è che tu compili la parte "metodo" con qualsiasi cosa renda sensata la condizione, il risultato e l'eccezione.
Sono felice di vedere una suite chiamata "MakingADeposit" con un test chiamato "AccountDoesntExist" e un errore che dice "Eccezione NonesuchAccount prevista - nessuna ricevuta."
In alternativa, se non ti dispiace separare il nome della suite di test con "::", sto bene con "AccountHandling :: MakingADeposit_AccountDoesntExist_ThrowsAnException"
La carta suggerisce anche che se non hai un buon nome, continua in avanti e dai un nome migliore quando ti viene in mente (speriamo bene prima di inviare il codice a CI).
Quindi il problema è che un nome corretto di funzionalità è troppo lungo per il nome di un metodo? So che è imbarazzante iniziare a scrivere metodi di prova con nomi come registerAndValidateUnderageUniversityDriverWithCoverageSetA_test() e potrebbe mai violare le regole del compilatore per i nomi di metodi lunghi (solo PL / SQL consente fino a 30 caratteri - non so se Java e C # impongono limiti di nome così brevi , ma anche se non lo fanno, passa a un certo punto e i nomi dei metodi veramente lunghi potrebbero essere utili solo per il codice generato che viene letto / gestito da un altro codice generato). Puoi provare ad abbreviare a regValUnderageUnivDrvrWCovrgA_test() , ma è anche molto orribile da leggere. Un'opzione che ho usato che non mi piaceva, ma che al momento era la scelta migliore era underageUnivDrvr_test_01() e poi c'era un foglio di calcolo che associava i nomi dei metodi a una descrizione molto più lunga della funzionalità testata. Brutto, ma ha funzionato. Puoi anche documentare la descrizione del test nella documentazione della funzione nel file sorgente, che potrebbe essere utile perché puoi generare documentazione dei test direttamente dal codice, invece di mappare avanti e indietro tra foglio elettronico e codice.
I test di integrazione dovrebbero seguire alcune regole simili ai test unitari in quanto ogni test dovrebbe testare un aspetto di un requisito ma testare il sistema nel suo complesso. La classe dovrebbe nominare la cosa complessiva che viene testata, ad es. "TpcInputValidation" e la denominazione del metodo dovrebbero riflettere espressamente ciò che il test sta tentando di fare senza essere eccessivamente prolisso, ad es. "ShouldRaiseValidationErrorWithBadDates ()".
I metodi dovrebbero testare un concetto della funzione e un gran numero di asseriti potrebbe indicare diversamente. (Rif. "Codice pulito: un manuale di abilità software agile", pagina 132, di Robert Martin).
Leggi altre domande sui tag testing integration-tests naming