Le mie classi hanno normalmente circa 5-20 metodi al massimo, ciò implica che la classe che ha i test unitari ha circa il doppio dei metodi (contando i datiProvider, setUp, ...)
Ho pensato di separare i test in 2-3 classi, perché anche se provo a seguire il principio di responsabilità singola, preferisco 2 classi di test con 10 metodi ciascuno, rispetto a uno con 20.
È una cattiva pratica ?? È bello avere tutti i test per una classe in una sola, sebbene la classe di test cresca in verticale?
Per rispondere alla domanda specifica, è assolutamente possibile che raggruppare i test in più classi è una buona decisione, evento quando la classe in esame è ben progettata.
Il codice di test unitario è come qualsiasi altro codice: dovrebbe seguire i principi del buon design ( DRY , GRASP , BACIO , SOLID , YAGNI , ecc.). Poiché la logica che costituisce il codice di test è spesso più semplice della logica del dominio, molti dei punti specifici non verranno visualizzati così tanto, ma tienilo a mente mentre scrivi i tuoi test lo stesso.
Ci sono un paio di principi che vengono in mente e che possono essere facilmente applicati quando si pensa alla tua domanda:
La leggibilità
Idealmente, una volta che un test è stato scritto, non devi mai più guardarlo; ma lo stesso si può dire per qualsiasi codice. La realtà è che i requisiti cambiano, quindi ci troviamo a leggere il codice molto più che scriverlo. Anche quando fai del tuo meglio, potresti scoprire che il test che hai scritto non ha affatto verificato ciò che pensavi di aver fatto, a quel punto dovresti tornare indietro e capire cosa c'era che non andava. Trovare quel metodo di prova in una classe di 40-50 metodi di test sarà dura, per non parlare della complicazione di nominare quei metodi in modo che possano essere facilmente differenziati.
Ogni classe di test (come qualsiasi altra classe) dovrebbe avere un focus chiaro. Se hai un sacco di diversi casi di test per un dato metodo della classe sotto test, come quando un determinato test verifica una singola cosa, metti quei metodi di prova in una classe separata e nominali per riflettere il suo focus.
Non è quasi affatto importante come siano organizzati i tuoi test unitari rispetto ad averli in primo luogo.
Un modulo o una classe di codice aziendale è qualcosa che devi capire come un'unità e svilupparla ulteriormente. Questo è il motivo principale per cui cerchiamo di renderlo coerente, facile da comprendere nel suo complesso, ecc. Una suite di test è solo una raccolta di casi che devono tutti passare; non hanno alcuna relazione particolare tra loro . Idealmente, non dovrai mai più occupartene; se lo fai, di solito devi aggiungere altri test che non hanno ancora alcuna relazione particolare con nessun altro test, e non vengono mai chiamati dal codice client tranne il framework di test dell'unità.
Pertanto, la questione su come organizzare le classi che contengono unit test è molto meno critica di come organizzare le classi che compongono la propria applicazione. Non dovresti comunque gestirli come una macrostruttura ben architettata.
Metti i test in un file. In genere per ogni file di classe avrei un file di test. Solitamente aggiungi "Test" al nome del file.
Per esempio, se c'è una classe chiamata "Foo" ci sarebbe un corrispondente file "FooTests". In questo modo per ogni file di codice esiste una relazione 1 a 1 tra il file di codice e il file di test.
Ciò fornisce coerenza e rende più facile per gli sviluppatori individuare i test e mantenerli aggiornati. I test sono solitamente esclusi dalle analisi / metriche del codice, quindi se il file è grande, non danneggia la metrica complessiva del codice, quindi non considero la cattiva forma avere un file di test con un sacco di codice di test unitario. p>
Se diciamo che la definizione di cattiva pratica nello sviluppo di software è qualcosa che non ti aiuta a gestire e incapsula il cambiamento, allora direi che non mantenere le tue lezioni e test in una relazione uno a uno è una cattiva pratica . È un odore di codice che potrebbe sorgere a causa delle cose menzionate di seguito.
Ovviamente ci sono delle eccezioni come in qualsiasi altra cosa, ma tienilo a mente mentre scrivi i test.
My Classes normally have about 5-20 methods maximum.
Se una delle tue classi ha 20 (o un po 'meno) metodi che mi mostrano che la classe sta facendo troppo in primo luogo. È qui che i test unitari dovrebbero suggerirti che potresti dover abbattere un po 'di più la tua classe e distribuire la responsabilità prima di andare sui test.
Per tenerli nella stessa classe o no suggerirei di provare a tenerli in una classe, se possibile, perché è meglio comprensibile - una connessione one to one è facile da cogliere dopo un sacco di il tempo è passato. Solo per esperienza.
Se vedi che i test unitari sono enormi anche quando hai 5 o meno metodi, allora mi dice che il tuo codice di configurazione sta facendo troppo o i tuoi oggetti sono anormalmente grandi .
Se non hai ancora provato, controlla il modello di build per costruire i tuoi oggetti - questo potrebbe ridurre drasticamente il codice su come stai costruendo i tuoi oggetti prima di provarli. Pertanto, rendendo la lezione di test unitario più breve e meno necessaria per ridurla in più classi.
Leggi altre domande sui tag unit-testing phpunit