Quale concetto mi manca con metodi e test privati? [duplicare]

Design per i test, ma non eseguire il codice per i test

Usi metodi privati per ridurre il codice. Meno codice è sempre più stabile. Estrarre un metodo privato in un'altra classe in modo che possa essere testato genera più codice e rende qualcosa che era nel dominio della classe ora una cosa esterna.

Se una classe è utilizzata solo da un'altra classe. Che le due classi siano rappresentazioni parziali di un'intera classe, allora hai un problema. Mentre i tuoi test unitari stanno per passare, non passeranno a lungo. Stanno per rompere. È come lavorare sul fissaggio di un tavolo pensando che si regge su 3 gambe quando infatti ce ne sono 4. La 4 ° tappa non è visibile quando ci stai lavorando.

Il design per i test significa che hai creato una raccolta di classi, interfacce e altre cose che rimarranno stabili man mano che la modifichi. Non ci dovrebbe essere un enorme effetto a catena quando si interrompe qualcosa (può esserci una causa a catena per dipendenza, ma il fallimento dovrebbe essere orizzontale. Non verticale).

Un utente di una classe vuole affidabilitàfirst. I test di unità dovrebbero mostrare che la classe è stabile in tutti gli stati possibili. È possibile rendere pubblico ogni metodo e ottenere una copertura del codice al 100%. Questo lo rende davvero più affidabile? No, non lo è.

Pensa innanzitutto, quali test unitari devo verificare per verificare che questa roba funzioni come previsto.

Avere un metodo privato double_price() non significa che debba essere testato. Probabilmente è chiamato poche decine di volte da diverse parti della classe. Raddoppia il prezzo, e ciò accade in molti posti, quindi è reused code.

Questo metodo rischia la stabilità? Se lo fa, chiediti "Il rischio giustifica una serie diversa di test unitari?" Se è così, incapsula e scrivi i test unitari per quello.

Pensa a questo.

Per costruire un sistema, vuoi utilizzare piccoli pezzi che sai funzionare. Se prendi pezzi A e B che conosci superare i test unitari, quindi crea C usando A e B rende C più stabile.

Non pensare come questo

Ho un sistema chiamato A . È stabile? Non lo so. Apriamo A e strappiamo B e C . Ora posso testare A , B e C .

Perché è così male? Perché questo può accadere. A e C superano i test unit ma B fallisce. In che modo A e C possono essere stabili? Perché non hai strappato A a parte correttamente. A è effettivamente instabile perché una parte di essa è che pretende di essere B .

oh uomo, penso di essermi appena fatto un mal di testa.

In un caso come quello che descrivi, terrei il metodo privato. I test (in particolare i test di unità) dovrebbero fornire una buona copertura della classe senza dover conoscere l'implementazione. Se i test sono troppo accoppiati all'implementazione (piuttosto che al comportamento desiderato), allora la classe si sentirà fragile e difficile da lavorare.

Se svolgi correttamente il tuo lavoro, il tuo metodo privato dovrebbe essere accuratamente testato (copertura del codice) indirettamente testando il comportamento della tua classe.

No, sarei completamente d'accordo con te e una logica simile mi è venuta in mente al college. In sostanza, ci siamo resi conto di renderlo privato in tutti i casi, a meno che non sia necessario accedervi da qualche altra parte.

Molte volte vorrei creare un metodo privato come metodo per ridurre la duplicazione del codice. Supponiamo che io abbia 3 metodi pubblici che a un certo punto necessitano di eseguire un codice simile. Non ho intenzione di fare un altro metodo pubblico che non sia necessario e possibilmente pericoloso se è un progetto di gruppo, non ho intenzione di avere il codice lì 3 volte rendendolo ingestibile, ho intenzione di fare un metodo privato e chiamare 3 volte, questa è la conoscenza di programmazione di base.

Per non testarlo? mai nella mia vita avrei finito un progetto senza testare un metodo ... deliberatamente ovviamente.

Trovo che le affermazioni che hai letto sui blog siano completamente ridicole, dovresti stare lontano da questi blog o autori in quanto non sono programmatori.