Scelta dei nomi per i test di integrazione

Con i test unitari il dominio è piuttosto piccolo, quindi è facile. Ho usato lo methodName_conditions_result()schema di Osherove e l'ho trovato molto chiaro.

Ma con i test di integrazione ho la sensazione che farebbe un nome molto lungo, e cosa metto al posto di methodName? Come posso denominare le classi di test di integrazione?

Sono benvenuti esempi reali di nomi di test di integrazione. Spero che le risposte mi aiuteranno anche a capire meglio questi test.

Ho un approccio un po 'diverso con i test unitari e di integrazione. Provo a nominarli il più possibile in base alle funzionalità. Quindi quando tutti i test passano puoi vedere un elenco di tutte le funzionalità che funzionano e non funzionano.

• canRegisterUser
• canHandleInvalidInput
• canRelayDocumentBetweenServers
• canCreateSchema
• canLoginUsingWebService
• canLoginUsingBasicAuth
• canDeleteDocument
• canAddDocument

Non è sempre pragmatico nominare i test in questo modo, ma può essere molto utile soprattutto dopo aver letto centinaia di test unitari e di integrazione. Il nome complessivo della classe che comprende questi metodi dovrebbe anche essere indicativo delle funzionalità da testare. Aiuterà con l'organizzazione.

Suggerirei anche di nominare qualsiasi test unitario per correzioni di bug con un prefisso univoco tale da bugfix1002dimostrare che il bug è stato corretto.

Questo è stato davvero scritto per aiutare con i unit test, ma forse scoprirai che le stesse regole si applicano (più o meno) ai test di integrazione:

Dai un'occhiata a Seven Steps !

La mia preferenza è che qualunque cosa tu lo chiami, in realtà è il nome della suite di test (nome del dispositivo sulla nostra carta), l'effetto che stai verificando e il messaggio di asserzione che deve risaltare e chiarire la causa dell'errore. Se trovi che è più facile con la denominazione di Asherove, allora lo sostengo con tutto il cuore. Ma forse il trucco è che riempi la parte "metodo" con qualunque cosa abbia senso la condizione, il risultato e l'eccezione.

Sono felice di vedere una suite denominata "MakingADeposit" con un test chiamato "AccountDoesntExist" e un errore che dice "Eccezione nonesuchAccount prevista - nessuna ricevuta".

In alternativa, se non ti dispiace se separo 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 e dai un nome migliore quando ti viene in mente (si spera bene prima di inviare il codice a CI).

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 insieme. La classe dovrebbe nominare la cosa generale che viene testata, ad esempio "TpcInputValidation" e la denominazione del metodo dovrebbe riflettere espressamente ciò che il test sta cercando di fare senza essere eccessivamente prolisso, ad esempio "shouldRaiseValidationErrorWithBadDates ()".

I metodi dovrebbero testare un concetto della funzionalità e un gran numero di affermazioni potrebbe indicare diversamente. (Rif. "Clean Code: A Handbook of Agile Software Craftrafts" p. 132, di Robert Martin).

Quindi il problema è che un nome proprio di funzionalità è troppo lungo per un nome di metodo? So che è strano iniziare a scrivere metodi di prova con nomi come registerAndValidateUnderageUniversityDriverWithCoverageSetA_test()e che potrebbero mai infrangere le regole del compilatore per nomi di metodi lunghi (PL / SQL consente solo fino a 30 caratteri - Non so se Java e C # impongano limiti di nomi così brevi, ma anche in caso contrario, passa un po 'a disagio oltre un certo punto e nomi di metodi davvero molto lunghi potrebbero essere utili solo per il codice generato che viene letto / gestito da altro codice generato). Puoi provare ad accorciarlo regValUnderageUnivDrvrWCovrgA_test()ma è anche orribile da leggere. Un'opzione che ho usato che non mi piaceva, ma era la scelta migliore al momento eraunderageUnivDrvr_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. È inoltre possibile documentare la descrizione del test nella documentazione della funzione nel file di origine, che potrebbe essere utile perché è possibile generare la documentazione dei test direttamente dal codice, anziché mappare avanti e indietro tra foglio di calcolo e codice.