Sto ancora imparando a fare del test di livello unit , dato che sono sempre stato un po 'trascurato nel fare solo test funzionali in passato, quindi voglio ricontrollare I' Sto facendo questo 'giusto'.
Ho un pacchetto che è responsabile per l'aggiornamento automatico di una particolare configurazione che dovrebbe cambiare regolarmente durante il runtime. Fornire un elenco di oggetti da monitorare al costruttore della mia classe di pacchetto principale. Quindi, ad un certo punto, l'aggiornamento delle chiamate passerà a tutte le diverse posizioni che definiscono la configurazione, rileva le modifiche, aggiorna lo stato appropriato per gli oggetti che sta monitorando e fornisce un rapporto su ciò che è stato modificato. Questo è tutto automatico e in altro modo trasparente per tutti gli altri pacchetti.
La mia inclinazione è quella di testarlo come un'unità, ma è un'unità piuttosto "grande", 5-6 classi e il recupero da più file e un'interfaccia riposante. Sembra che testare qualsiasi unità più piccola richiederebbe molto più tempo, essere meno flessibile per il refactoring e fornire solo una probabilità leggermente superiore di rilevare un difetto, ma potrebbe essere solo la mia pigrizia a parlare. Sarebbe considerato "migliore" testare a un livello inferiore?
Supponendo che sia 'giusto' testare il pacchetto come un'unità che è considerata appropriata per deridere qualcosa del genere? Ci sono metodi di classi che sono istanziati dalla mia classe principale (cioè, non qualcosa che passo direttamente in modo che io non possa passare il mio stesso finto) che abbia metodi che voglio controllare. Credo di poter usare powerMock nei due casi a cui riesco a pensare (o potrei, dopo aver ricercato ancora PowerMock), ma non sono sicuro che farlo sia abbastanza trasparente. Sta configurando PowerMock per rilevare e restituire un oggetto file di simulazione ogni volta che il mio pacchetto tenta di aprire un file di configurazione, anche se è sepolto in profondità nella logica del mio pacchetto, accettabile, o si ritiene che stia abusando della mia conoscenza dei dettagli specifici dell'implementazione? Sarebbe "più pulito" modificare effettivamente i file di configurazione sul file system e lasciarli leggere normalmente senza ulteriori derisioni? Avrei bisogno di modificare i file regolarmente per testare ...
Modifica: Per chiarire la questione dell'accoppiamento chiesto in una delle domande, non penso che le mie lezioni siano eccessivamente accoppiate. Effettivamente ho tre classi che recuperano lo stato da A, B e C, e quindi una classe 'principale' che prende lo stato dal tre e decide come combinarlo correttamente (cioè, se A e B non corrispondono all'uso A a meno che C). Potrei facilmente testare A B e C separatamente e poi deriderli per testare la mia classe 'principale'. Tuttavia, sembra che il test della mia classe "principale" testerebbe in ogni caso le interfacce comparativamente semplici per A, B e C se non le prendevo in giro. Quindi sembra un lavoro duplicato per testarli individualmente. Potrei ottenere una copertura del codice leggermente migliore, forse, con test individuali, ed è sempre bello avere un test solo una cosa. Ma non so se valga la pena coprire tutti i costi per benefici minori.