Riutilizzo dell'array con dati di test statici su classi di test

Question

Riutilizzo dell'array con dati di test statici su classi di test

#1 da (3 voti)

2

Ho una mappa che contiene una chiave String e una matrice di oggetti personalizzati come valore. la mappa di solito contiene due voci e gli array per entrambe le voci non cambiano mai in termini di dati; una volta che sono popolati (uno, ad esempio, è un array di 50 oggetti di stato) non cambiano. Ho seguito la pratica che tutti i test dovrebbero essere autonomi, cioè ogni classe di test dovrebbe avere i propri dati per test per ridurre dipendenze e simili, ma ho ripetuto l'inizializzazione e la popolazione di questi array attraverso due diverse classi di test, con il potenziale di doverlo fare ancora per un altro paio di classi di test.

Può essere considerata una buona pratica avere questa creazione di array spostata in una classe di utilità separata esclusivamente per il test?

tdd unit-testing patterns-and-practices junit

posta jbailie1991 14.12.2015 - 12:45

fonte

1 risposta

Leggi altre domande sui tag tdd unit-testing patterns-and-practices junit

Passare campi (variabili d'istanza) per argomenti (parametri) all'interno di un oggetto - ha senso? [duplicare] E 'possibile non avere un array con indice zero con javascript? [chiuso]

score 3 · Answer 1

I test sono codice, e come tale dovrebbero essere applicate le migliori pratiche: il codice ripetuto dovrebbe probabilmente essere estratto in un metodo. Tuttavia, questo deve essere bilanciato:

I test dovrebbero essere molto, molto ovvi, molto più di altri codici. Uno strato di astrazione che rende difficile capire cosa fa un test e perché esattamente dovrebbe passare, potrebbe rendere inutilmente difficile il debug di un errore di test.
Le modifiche al metodo di inizializzazione estratto influiscono su tutti i test che usano quel metodo, anche se questo non è inteso. Pertanto, l'inizializzazione comune dovrebbe essere utilizzata solo se è vostra intenzione che tutti questi test utilizzino la stessa apparecchiatura di prova, e non dove questo sia un dettaglio accidentale di implementazione del test.
Se hai uno stato condiviso, questo rende i tuoi test più fragili. Un metodo che crea un dispositivo nuovo è preferibile rispetto allo stato condiviso. In particolare, sono molto critico nei metodi setUp() / tearDown() comuni in alcuni framework. Invece, il dispositivo di prova dovrebbe essere separato dalla classe che detiene i metodi di prova, e ogni test dovrebbe istanziare il proprio dispositivo.