Perché i metodi privati ​​di unit test sono considerati cattive pratiche?

Contesto:

Attualmente sto lavorando a un piccolo progetto in Python. Strutturo comunemente le mie classi con alcuni metodi pubblici che sono documentati ma riguardano principalmente i concetti di alto livello (ciò che un utente della classe dovrebbe conoscere e usare) e un mucchio di metodi nascosti (che iniziano con il trattino basso) che si occupano del elaborazione complessa o di basso livello.

So che i test sono essenziali per dare fiducia al codice e per garantire che eventuali modifiche successive non abbiano rotto il comportamento precedente.

Problema:

Al fine di costruire metodi pubblici di livello superiore su una base attendibile, generalmente collaudo i metodi privati. Trovo più facile scoprire se una modifica del codice ha introdotto regressioni e dove. Ciò significa che tali test interni possono violare revisioni minori e dovranno essere riparati / sostituiti

Ma so anche che il metodo privato di unit testing è almeno un concetto controverso o più spesso considerato una cattiva pratica. Il motivo è: solo il comportamento pubblico dovrebbe essere testato ( rif. )

Domanda:

Mi interessa seguire le migliori pratiche e vorrei capire:

• perché usare i test unitari su metodi privati ​​/ nascosti è male (qual è il rischio)?
• quali sono le migliori pratiche quando i metodi pubblici possono utilizzare elaborazioni di basso livello e / o complesse?

precisioni:

• non è un modo di mettere in discussione. Python non ha un vero concetto di privacy e i metodi nascosti non sono semplicemente elencati ma possono essere utilizzati quando si conosce il loro nome
• Non mi sono mai state insegnate regole e schemi di programmazione: le mie ultime lezioni sono degli anni '80 ... Ho imparato principalmente le lingue da prove e fallimenti e riferimenti su Internet (Stack Exchange è il mio preferito da anni)

Un paio di motivi:

1. In genere quando sei tentato di testare il metodo privato di una classe, è un odore di design (classe iceberg, componenti pubblici non riutilizzabili, ecc.). C'è quasi sempre qualche problema "più grande" in gioco.

2. Puoi testarli attraverso l'interfaccia pubblica (che è come li vuoi testare, perché è così che il client li chiamerà / li utilizzerà). Puoi ottenere un falso senso di sicurezza vedendo il via libera su tutti i test di superamento per i tuoi metodi privati. È molto meglio / più sicuro testare casi limite sulle tue funzioni private attraverso la tua interfaccia pubblica.

3. Rischi una duplicazione grave dei test (test che sembrano / sembrano molto simili) testando metodi privati. Ciò ha conseguenze importanti quando i requisiti cambiano, poiché molti più test del necessario si interromperanno. Può anche metterti in una posizione in cui è difficile eseguire il refactoring a causa della tua suite di test ... che è la massima ironia, perché la suite di test è lì per aiutarti a riprogettare e refactoring in sicurezza!

Un consiglio se sei ancora tentato di testare le parti private (non usarlo se ti dà fastidio e YMMV, ma in passato ha funzionato bene per me): a volte scrivere test unitari per funzioni private solo per essere sicuri stanno funzionando esattamente come pensi che possano essere utili (specialmente se non conosci una lingua). Tuttavia, dopo aver verificato che funzionano, elimina i test e assicurati sempre che test di fronte pubblico siano solidi e cattureranno se qualcuno apporta una modifica significativa a detta funzione privata.

Quando testare metodi privati: poiché questa risposta è diventata (in qualche modo) popolare, mi sento obbligato a dire che una "best practice" è sempre proprio questo: una "best practice". Ciò non significa che dovresti farlo dogmaticamente o alla cieca. Se ritieni di dover testare i tuoi metodi privati ​​e avere un motivo legittimo (come se stessi scrivendo test di caratterizzazione per un'applicazione legacy), quindi testa i tuoi metodi privati . Le circostanze specifiche prevalgono sempre su qualsiasi regola generale o migliore pratica. Basta essere consapevoli di alcune delle cose che possono andare storte (vedi sopra).

Ho una risposta che approfondisce questo argomento in dettaglio su SO che non ripeterò qui: /programming/105007/should-i-test-private-methods-or-only-public-ones/ 47401015 # 47401015

Dato che uno degli scopi principali dei test unitari è che puoi refactoring gli interni del tuo programma e quindi essere in grado di verificare che non hai rotto la sua funzionalità, è controproducente se i test unitari funzionano a un livello di granularità così fine che qualsiasi modifica al codice del programma richiede di riscrivere i test.

La scrittura di unit test per metodi privati collega i test unitari ai dettagli di implementazione.

I test unitari dovrebbero testare il comportamento di una classe sulla superficie esterna della classe (è un'API pubblica). I test unitari non dovrebbero sapere nulla delle viscere di una classe. Scrivere test unitari contro i dettagli di implementazione di una classe ti lega le mani quando arriva il momento di refactoring. Il refactoring quasi sicuramente supererà questi test, perché non fanno parte dell'API stabile.

Detto questo, perché potresti voler scrivere unit test per i tuoi metodi privati?

C'è una tensione naturale tra i test unitari e lo sviluppo incrementale. Gli sviluppatori di software che usano un REPL (read-eval-print loop) possono attestare quanto può essere produttivo scrivere e testare rapidamente piccoli frammenti di funzionalità mentre "cresci" una classe o una funzione. L'unico buon modo per farlo in ambienti che sono guidati da test unitari è scrivere test unitari per metodi privati, ma c'è molto attrito nel farlo. I test unitari richiedono tempo per essere scritti, è necessario un metodo effettivo per il test e il framework di test deve supportare la capacità di mantenere il metodo privato in modo da non inquinare l'API esterna.

Alcuni ecosistemi come C # e .NET hanno modi per creare ambienti simili a REPL (strumenti come Linqpad lo fanno), ma la loro utilità è limitata perché non si ha accesso al proprio progetto. La finestra immediata in Visual Studio è scomoda; non ha ancora Intellisense completo, devi usare nomi completi e innesca una build ogni volta che lo usi.

Dalla mia esperienza ho scoperto che unità che verifica le classi interne, i metodi di solito significano che devo prendere le funzioni testate, le classi fuori. Per creare un altro livello di astrazione.

Ciò porta a una migliore aderenza al principio della responsabilità unica.

Penso che questa sia una buona domanda perché espone un problema comune nel testare la copertura. Ma una buona risposta dovrebbe dirvi che la questione non è esattamente giusto, perché, in teoria, si dovrebbe non essere in grado di unit test privati metodi. Ecco perché sono privati .

Forse una domanda migliore sarebbe "Cosa devo fare quando voglio testare metodi privati?"e la risposta è in qualche modo ovvia: dovresti esporli in modo da rendere possibili i test. Ora, questo non significa necessariamente che dovresti semplicemente rendere pubblico il metodo e basta. Molto probabilmente vorrai fare un'astrazione più alta; passare a una libreria o API diversa in modo da poter eseguire i test su quella libreria, senza esporre quella funzionalità nell'API principale.

Ricorda che c'è un motivo per cui i tuoi metodi hanno livelli di accessibilità diversi e dovresti sempre pensare a come verranno utilizzate le tue classi alla fine.