Come funzionano insieme lo sviluppo orientato ai test e il principio aperto/chiuso?

Question

Ho letto i test di unità, TDD e i principi SOLID e ho bisogno di alcuni chiarimenti. La mia comprensione è che se si aderisce al principio aperto/chiuso, il test dell'unità potrebbe diventare in gran parte inutile a causa del fatto che il codice è chiuso alla modifica, quindi non è necessario ripetere il test se il codice è correttamente isolato e disaccoppiato. Il beneficio a lungo termine del costo iniziale aggiunto dei test unitari viene perso se una volta che il codice supera i test unitari relativi, non cambierà. Il codice passerà sempre perché non cambierà mai, giusto? Le classi ereditate dovranno essere testate, ma una volta che avranno superato i test correlati, anch'essi saranno chiusi alle modifiche e non avranno bisogno di essere ritestati. The Wikipedia article on OCP rafforza questa linea di pensiero nel primo paragrafo (mi rendo conto che non lo rende legge).
La migliore spiegazione che ho trovato per OCP e TDD che vivono in armonia is here, anche se sembra che Arnon stia dicendo che OCP si complimenta con TDD in quanto lo sviluppatore è scoraggiato dal modificare il codice sorgente perché i metodi di test esistenti possono diventare complessi quando modificati per testare nuova funzionalità.
È tutto quello che c'è da fare? Intendiamoci che non sto cercando una discussione, sono nuovo a questo e sto cercando un chiarimento da quelli con più esperienza rispetto a me.

Answer 1

Anche se dovessi accettare che una volta che il software funzioni e non cambia, non è necessario testarlo (cosa che non faccio), è comunque necessario mostrare che un componente funziona nel primo posto. Direi che uno dei modi migliori per farlo è un (i) test (i) unitario (i).

Inoltre, in pratica, una volta eseguito il test, costa pochissimo a eseguirlo. Quindi, anche se i componenti non cambiano, non stai perdendo molto eseguendo continuamente i test. Inoltre, a volte il design cambia ed è necessario tornare indietro e ripetere alcuni componenti - con test unitari sicuramente aiuta in questo caso ...

Ricorda, un risultato di avere una suite di test è che promuove la mantenibilità mostrando quando qualcosa i cambiamenti. Quindi, anche se il tuo team sta seguendo la O in SOLID, ciò non significa che le cose non verranno modificate accidentalmente. Quindi i test aiutano lì mostrando se qualcosa è cambiato inavvertitamente, e ti mostrano esattamente ciò che è stato influenzato dal cambiamento.

Answer 2

test di unità potrebbe diventare in gran parte inutile a causa del fatto che il codice è chiuso a modifiche

Beh, non a tutti. Come conosci l'originale, chiuso, l'implementazione è corretta?

Il beneficio a lungo termine del costo iniziale aggiunto di unit testing è persa

Un importante ritrovamento di economia ingegneria del software è che è molto più costoso per rilevare e correggere un difetto nel corso della vita di un Prodotto. IIRC, di circa un ordine di grandezza per ogni fase di un classico processo di sviluppo "a cascata". Poiché i test unitari (sia TDD che test-first) rilevano tempestivamente i difetti, possono recuperare rapidamente i loro costi.

non cambierà

Se ha un difetto in esso dovrà essere cambiato. Naturalmente, se puoi garantire che il tuo codice sia privo di difetti, ciò che dici è vero. Ma se è possibile garantire che non è necessario qualsiasi tipo di test. Ma pochissimi progetti software possono fare una simile affermazione.