Devo evitare i metodi privati ​​se eseguo TDD?

Sto imparando solo TDD. Comprendo che i metodi privati ​​non sono verificabili e non dovrebbero essere preoccupati perché l'API pubblica fornirà informazioni sufficienti per verificare l'integrità di un oggetto.

Ho capito OOP per un po '. Comprendo che i metodi privati ​​rendono gli oggetti più incapsulati, quindi più resistenti ai cambiamenti e agli errori. Pertanto, dovrebbero essere utilizzati per impostazione predefinita e solo quei metodi che contano per i clienti dovrebbero essere resi pubblici.

Bene, è possibile per me creare un oggetto che ha solo metodi privati ​​e interagisce con altri oggetti ascoltando i loro eventi. Questo sarebbe molto incapsulato, ma completamente non verificabile.

Inoltre, è considerata una cattiva pratica aggiungere metodi a scopo di test.

Questo significa che TDD è in contrasto con l'incapsulamento? Qual è il giusto equilibrio? Sono propenso a rendere pubblici la maggior parte o tutti i miei metodi ora ...

Preferisci test all'interfaccia piuttosto che test sull'implementazione.

Comprendo che i metodi privati ​​non sono verificabili

Questo dipende dal tuo ambiente di sviluppo, vedi sotto.

[metodi privati] non dovrebbero essere preoccupati perché l'API pubblica fornirà informazioni sufficienti per verificare l'integrità di un oggetto.

Esatto, TDD si concentra sul test dell'interfaccia.

I metodi privati ​​sono dettagli di implementazione che potrebbero cambiare durante qualsiasi ciclo di rifattoriale. Dovrebbe essere possibile ricodificare senza modificare l'interfaccia o il comportamento della scatola nera . In effetti, ciò fa parte del vantaggio di TDD, la facilità con cui è possibile generare la sicurezza che le modifiche interne a una classe non influiranno sugli utenti di quella classe.

Bene, è possibile per me creare un oggetto che ha solo metodi privati ​​e interagisce con altri oggetti ascoltando i loro eventi. Questo sarebbe molto incapsulato, ma completamente non verificabile.

Anche se la classe non ha metodi pubblici, i gestori di eventi sono l' interfaccia pubblica ed è contro quell'interfaccia pubblica che puoi testare.

Poiché gli eventi sono l'interfaccia, sono gli eventi che dovrai generare per testare quell'oggetto.

Cerca di usare oggetti finti come colla per il tuo sistema di test. Dovrebbe essere possibile creare un semplice oggetto simulato che genera un evento e rileva il conseguente cambio di stato (possibile tramite un altro oggetto simulato del ricevitore).

Inoltre, è considerata una cattiva pratica aggiungere metodi a scopo di test.

Assolutamente, dovresti essere molto cauto nell'esporre lo stato interno.

Questo significa che TDD è in contrasto con l'incapsulamento? Qual è il giusto equilibrio?

Assolutamente no.

TDD non dovrebbe cambiare l'implementazione delle tue classi se non forse per semplificarle (applicando YAGNI da un punto precedente).

Le migliori pratiche con TDD sono identiche alle migliori pratiche senza TDD, basta scoprire perché prima, perché stai usando l'interfaccia mentre la sviluppi.

Sono propenso a rendere pubblici la maggior parte o tutti i miei metodi ora ...

Questo sarebbe piuttosto buttare via il bambino con l'acqua del bagno.

Non è necessario rendere pubblici tutti i metodi in modo da poterli sviluppare in modo TDD. Vedi le mie note di seguito per vedere se i tuoi metodi privati ​​non sono realmente verificabili.

Uno sguardo più dettagliato al test di metodi privati

Se devi assolutamente provare unitamente alcuni comportamenti privati ​​di una classe, a seconda della lingua / ambiente, potresti avere tre opzioni:

1. Inserisci i test nella classe che desideri testare.
2. Inserisci i test in un altro file di classe / sorgente ed esponi i metodi privati ​​che desideri testare come metodi pubblici.
3. Utilizzare un ambiente di test che consenta di mantenere separato il codice di test e di produzione, consentendo comunque l'accesso al codice di test ai metodi privati ​​del codice di produzione.

Ovviamente la terza opzione è di gran lunga la migliore.

1) Metti i test nella classe che vuoi testare (non ideale)

Memorizzare i casi di test nello stesso file di classe / sorgente del codice di produzione sotto test è l'opzione più semplice. Ma senza molte direttive o annotazioni pre-processore finirai con il tuo codice di test che gonfia inutilmente il tuo codice di produzione e, a seconda di come hai strutturato il tuo codice, potresti finire per esporre accidentalmente l'implementazione interna agli utenti di quel codice.

2) Esporre i metodi privati ​​che si desidera testare come metodi pubblici (davvero non è una buona idea)

Come suggerito, questa è una pratica molto scadente, distrugge l'incapsulamento e esporrà l'implementazione interna agli utenti del codice.

3) Utilizzare un ambiente di test migliore (opzione migliore, se disponibile)

Nel mondo Eclipse, 3. può essere ottenuto usando frammenti . Nel mondo C #, potremmo usare classi parziali . Altre lingue / ambienti hanno spesso funzionalità simili, devi solo trovarle.

Supponendo ciecamente 1. o 2. sono le uniche opzioni che potrebbero comportare un software di produzione gonfio con codice di test o interfacce di classe sgradevoli che lavano la biancheria sporca in pubblico. * 8' )

• Tutto sommato, è molto meglio non testare contro l'implementazione privata.

Ovviamente puoi avere metodi privati ​​e ovviamente puoi provarli.

O c'è un modo per far funzionare il metodo privato, nel qual caso puoi provarlo in quel modo, o non c'è modo di far funzionare il privato, nel qual caso: perché diamine stai provando a provarlo, solo elimina la dannata cosa!

Nel tuo esempio:

Bene, è possibile per me creare un oggetto che ha solo metodi privati ​​e interagisce con altri oggetti ascoltando i loro eventi. Questo sarebbe molto incapsulato, ma completamente non verificabile.

Perché non sarebbe testabile? Se il metodo viene invocato in risposta a un evento, fare in modo che il test dia all'oggetto un evento appropriato.

Non si tratta di non avere metodi privati, non di rompere l'incapsulamento. Puoi avere metodi privati ​​ma dovresti testarli attraverso l'API pubblica. Se l'API pubblica si basa su eventi, utilizzare gli eventi.

Per il caso più comune di metodi di supporto privati, possono essere testati attraverso i metodi pubblici che li chiamano. In particolare, poiché ti è permesso solo scrivere codice per far passare un test non riuscito e i tuoi test stanno testando l'API pubblica, tutto il nuovo codice che scrivi sarà di solito pubblico. I metodi privati ​​vengono visualizzati come risultato di un refactoring del metodo di estrazione , quando vengono estratti da un metodo pubblico già esistente. Ma in quel caso, il test originale che verifica il metodo pubblico copre ancora anche il metodo privato, poiché il metodo pubblico chiama il metodo privato.

Quindi, di solito i metodi privati ​​compaiono solo quando sono estratti da metodi pubblici già testati e sono quindi già testati.

Quando crei una nuova classe nel tuo codice, lo fai per rispondere ad alcuni requisiti. I requisiti indicano cosa deve fare il codice, non come . Questo rende facile capire perché la maggior parte dei test avvenga a livello di metodi pubblici.

Attraverso i test, verifichiamo che il codice fa quello che dovrebbe fare , genera opportune eccezioni quando previsto, ecc. Non ci interessa davvero come il codice viene implementato dallo sviluppatore. Anche se non ci interessa l'implementazione, ovvero come il codice fa quello che fa, ha senso evitare di testare metodi privati.

Per quanto riguarda le lezioni di test che non hanno metodi pubblici e interagiscono con il mondo esterno solo attraverso eventi, è possibile testare anche questo inviando, attraverso test, gli eventi e ascoltando la risposta. Ad esempio, se una classe deve salvare un file di registro ogni volta che riceve un evento, l'unità test invierà l'evento e verificherà che il file di registro sia stato scritto.

Ultimo ma non meno importante, in alcuni casi è perfettamente valido testare metodi privati. Ecco perché, ad esempio, in .NET, puoi testare non solo le classi pubbliche, ma anche quelle private, anche se la soluzione non è così semplice come per i metodi pubblici.

Comprendo che i metodi privati ​​non sono verificabili

Non sono d'accordo con questa affermazione, o direi che non testare direttamente i metodi privati . Un metodo pubblico può chiamare diversi metodi privati. Forse l'autore voleva avere metodi "piccoli" ed estrarre parte del codice in un metodo privato abilmente chiamato.

Indipendentemente da come viene scritto il metodo pubblico, il codice di test dovrebbe coprire tutti i percorsi. Se, dopo i test, scopri che una delle istruzioni della filiale (if / switch) in un metodo privato non è mai stata coperta nei test, allora hai un problema. O hai perso un caso e l'implementazione è corretta OPPURE l'implementazione è sbagliata e quel ramo in realtà non dovrebbe mai esistere.

Questo è il motivo per cui uso molto Cobertura e NCover, per assicurarmi che il mio test del metodo pubblico copra anche i metodi privati. Sentiti libero di scrivere buoni oggetti OO con metodi privati ​​e non lasciare che TDD / Test vadano sulla tua strada in tale materia.

Il tuo esempio è ancora perfettamente testabile finché usi Dependency Injection per fornire le istanze con cui il tuo CUT interagisce. Quindi è possibile utilizzare un finto, generare gli eventi di interesse e quindi osservare se il CUT esegue o meno le azioni corrette sulle sue dipendenze.

D'altra parte, se hai una lingua con un buon supporto per gli eventi, potresti prendere una strada leggermente diversa. Non mi piace quando gli oggetti si iscrivono agli eventi stessi, invece hanno la fabbrica che crea l'oggetto che collega gli eventi ai metodi pubblici dell'oggetto. È più facile da testare e rende esternamente visibile per quali tipi di eventi il ​​CUT deve essere testato.

Non dovresti aver bisogno di abbandonare usando metodi privati. È perfettamente ragionevole usarli, ma dal punto di vista dei test è più difficile testarli direttamente senza interrompere l'incapsulamento o aggiungere codice specifico del test alle classi. Il trucco è ridurre al minimo le cose che sai che faranno vacillare il tuo istinto perché ti senti come se avessi sporcato il tuo codice.

Queste sono le cose che tengo a mente per cercare di raggiungere un equilibrio praticabile.

1. Ridurre al minimo il numero di metodi e proprietà privati ​​utilizzati. La maggior parte delle cose che devi fare in classe tende ad essere comunque esposta pubblicamente, quindi pensa a se hai davvero bisogno di rendere privato quel metodo intelligente.
2. Riduci al minimo la quantità di codice nei tuoi metodi privati ​​- dovresti comunque farlo comunque - e verifica indirettamente dove puoi tramite il comportamento di altri metodi. Non ti aspetti mai di ottenere una copertura del test al 100% e forse dovrai controllare manualmente alcuni valori tramite il debugger. L'uso di metodi privati ​​per generare eccezioni può essere facilmente testato indirettamente. Potrebbe essere necessario testare le proprietà private manualmente o tramite un altro metodo.
3. Se il controllo indiretto o manuale non ti soddisfa, aggiungi un evento protetto e accedi tramite un'interfaccia per esporre alcune cose private. Questo "piega" efficacemente le regole dell'incapsulamento, ma evita la necessità di spedire effettivamente il codice che esegue i test. Lo svantaggio è che ciò può comportare un piccolo codice interno aggiuntivo per assicurarsi che l'evento venga generato quando necessario.
4. Se ritieni che un metodo pubblico non sia abbastanza "sicuro", vedi se ci sono modi in cui puoi implementare una sorta di processo di validazione nei tuoi metodi per limitare il loro utilizzo. È probabile che mentre stai pensando a questo o pensi a un modo migliore per implementare i tuoi metodi, o vedrai un'altra classe che inizia a prendere forma.
5. Se hai molti metodi privati ​​che fanno "cose" per i tuoi metodi pubblici, potrebbe esserci una nuova classe in attesa di essere estratta. Puoi testarlo direttamente come una classe separata, ma implementarlo come un composto privatamente all'interno della classe che lo utilizza.

Pensa lateralmente. Mantieni le tue classi piccole e i tuoi metodi più piccoli e usa molta composizione. Sembra più lavoro, ma alla fine ti ritroverai con più oggetti individualmente testabili, i tuoi test saranno più semplici, avrai più opzioni per usare semplici mock al posto di oggetti reali, grandi e complessi, si spera bene- codice fattorizzato e debolmente accoppiato e, cosa più importante, ti darai più opzioni. Mantenere le cose piccole tende a farti risparmiare tempo alla fine, perché riduci il numero di cose che devi controllare individualmente su ogni classe e tendi a ridurre naturalmente il codice spaghetti che a volte può accadere quando una classe diventa grande e ha un sacco di comportamento del codice interdipendente internamente.

Bene, è possibile per me creare un oggetto che ha solo metodi privati ​​e interagisce con altri oggetti ascoltando i loro eventi. Questo sarebbe molto incapsulato, ma completamente non verificabile.

Come reagisce questo oggetto a quegli eventi? Presumibilmente, deve invocare metodi su altri oggetti. Puoi testarlo verificando se questi metodi vengono chiamati. Fallo chiamare un oggetto finto e poi puoi facilmente affermare che fa quello che ti aspetti.

Il problema è che vogliamo solo testare l'interazione dell'oggetto con altri oggetti. Non ci importa cosa succede dentro un oggetto. Quindi no, non dovresti avere più metodi pubblici di prima.

Ho anche lottato con questo stesso problema. Davvero, il modo per aggirare il problema è questo: come ti aspetti che il resto del tuo programma si interfaccia con quella classe? Metti alla prova la tua classe di conseguenza. Questo ti costringerà a progettare la tua classe in base a come il resto del programma si interfaccia con essa e, di fatto, incoraggerà l'incapsulamento e il buon design della tua classe.

Invece del modificatore predefinito di uso privato. Quindi puoi testare questi metodi singolarmente, non solo accoppiato con metodi pubblici. Ciò richiede che i test abbiano la stessa struttura del pacchetto del codice principale.

Alcuni metodi privati ​​di solito non sono un problema. Li testi semplicemente attraverso l'API pubblica come se il codice fosse incorporato nei tuoi metodi pubblici. Un eccesso di metodi privati può essere un segno di scarsa coesione. La tua classe dovrebbe avere una responsabilità coesa e spesso le persone rendono i metodi privati ​​per dare l'apparenza di coesione laddove non esiste davvero.

Ad esempio, potresti avere un gestore eventi che effettua molte chiamate al database in risposta a quegli eventi. Dato che è ovviamente una cattiva pratica istanziare un gestore di eventi per effettuare chiamate al database, la tentazione è di rendere tutti i metodi privati ​​delle chiamate relative al database, quando dovrebbero essere effettivamente estratti in una classe separata.

Questo significa che TDD è in contrasto con l'incapsulamento? Qual è il giusto equilibrio? Sono propenso a rendere pubblici la maggior parte o tutti i miei metodi ora.

TDD non è in contrasto con l'incapsulamento. Prendi l'esempio più semplice di un metodo getter o di una proprietà, a seconda della lingua che preferisci. Diciamo che ho un oggetto Cliente e voglio che abbia un campo ID. Il primo test che scriverò è quello che dice qualcosa come "customer_id_initializes_to_zero". Definisco il getter per lanciare un'eccezione non implementata e guardare il test fallire. Quindi, la cosa più semplice che posso fare per fare quel passaggio di test è avere il ritorno a zero zero.

Da lì, vado su altri test, presumibilmente quelli che coinvolgono l'ID cliente in un campo reale e funzionale. Ad un certo punto, probabilmente dovrò creare un campo privato che la classe del cliente utilizza per tenere traccia di ciò che dovrebbe essere restituito dal getter. Come faccio a tenerne traccia esattamente? È un semplice supporto int? Tengo traccia di una stringa e poi la converto in int? Tengo traccia di 20 ints e li faccio in media? Al mondo esterno non importa e ai tuoi test TDD non importa. Questo è un dettaglio incapsulato .

Penso che questo non sia sempre immediatamente evidente quando si avvia TDD - non si stanno testando quali metodi fanno internamente - si stanno testando preoccupazioni meno granulari della classe. Quindi, non stai cercando di testare quel metodo che DoSomethingToFoo()crea un'istanza di una barra, chiama un metodo su di essa, ne aggiunge due a una delle sue proprietà, ecc. Stai testando che dopo aver mutato lo stato del tuo oggetto, alcuni accessor dello stato sono cambiati (o no). Questo è lo schema generale dei tuoi test: "quando faccio X alla mia classe sotto test, posso successivamente osservare Y". Il modo in cui si arriva a Y non è una preoccupazione dei test, e questo è ciò che è incapsulato ed è per questo che TDD non è in contrasto con l'incapsulamento.

Evitare di utilizzare? No.
Evitare di iniziare ? Sì.

Ho notato che non hai chiesto se è giusto avere lezioni astratte con TDD; se capisci come emergono le classi astratte durante il TDD, lo stesso principio si applica anche ai metodi privati.

Non puoi testare direttamente metodi in classi astratte proprio come non puoi testare direttamente metodi privati, ma è per questo che non inizi con classi astratte e metodi privati; inizi con classi concrete e API pubbliche e poi rifletti le funzionalità comuni mentre procedi.