Un progetto che utilizza TDD corretto ha un sacco di codice senza test?

Question

Un progetto che utilizza TDD corretto ha un sacco di codice senza test?

#1 da (7 voti)

3

Most (tutti?) TDD risorse ti mostrano come va il ciclo:

Scrivi test
Verifica test
Scrivi codice di produzione
Verifica test
Pulisci codice produzione
Verifica test

Anche loro - per me - sembrano implicare che tutto il codice è coperto dai test .

Tuttavia, leggere post come Writing Great Unit Test: Best and Worst Practices (ad esempio, collegato a qui ) si dice che

TDD is a robust way of designing software components (“units”) interactively so that their behaviour is specified through unit tests

Per inserire un altro contesto:

At the other end of the scale, integration tests contain no knowledge about how your codebase is broken down into units, but instead make statements about how the whole system behaves towards an external user.

Questo ha perfettamente senso per me. Tuttavia, implica che parti di grandi dimensioni delle codice delle applicazioni sono non coperte dai test . Perché? Perché se hai unità (e hai bisogno di un sacco di unità per ottenere i tuoi Test di unità a posto) hai bisogno di un codice che colleghi le unità. Questo codice, IMHO, sarà abbastanza complicato da meritare di essere testato a un livello più granulare che i test di integrazione, mentre probabilmente ricade in "Dirty Hybris":

Anywhere in between, it’s unclear what assumptions you’re making and what you’re trying to prove. Refactoring might break these tests, or it might not, regardless of whether the end-user experience still works

Quindi riassumendo:

Vedo facilmente il valore dei test Unità con TDD
È necessario un codice per collegare insieme le unità
Questo codice sarà complesso e il test di integrazione sarà / potrebbe non essere sufficiente.
Le risorse TDD in rete sembrano implicare il 100% di copertura del codice / test, tuttavia
guardare TDD con i test delle unità reali lascerà un codice non testato

Modifica: dice wikipedia :

Integration testing takes as its input modules that have been unit tested

ma in qualche modo ritengo che ci sia ancora un bel po 'di codice di cablaggio mancante nell'immagine. (eccetto se "modulo" significa "classe o funzione" perché quello è l'unità testata in isolamento)

Approfondimenti?

tdd unit-testing integration-tests

posta Martin Ba 04.10.2011 - 15:04

fonte

1 risposta

Leggi altre domande sui tag tdd unit-testing integration-tests

A che punto un'azienda ha bisogno di un ingegnere di sistema? Mescola tre licenze diverse per un software open-source

score 7 · Accepted Answer

However, it implies that large parts of the applications code are not covered by tests. Why? Because if you have units (and you need a lot of units to get your Unit Tests right) you need code that wires the units together. This code, IMHO, will get complicated enough that it deserves to be tested on a more granular level that integration tests while it probably falls into "Dirty Hybris":

La tua ipotesi è errata perché stai trascurando uno strato di test - test di accettazione.

I tuoi test unitari coprono singole unità - le classi e i metodi che le compongono. Ciò consente di testare metodi e classi in isolamento per garantire che si comportino come previsto. Al di sopra di questo si trovano i test di integrazione, che testano la collaborazione tra le classi e garantiscono che i moduli più grandi (pacchetti e persino la collaborazione tra pacchetti) funzionino come previsto. Infine, i test di accettazione vengono utilizzati per verificare e convalidare l'intero sistema, come assemblato, in base ai requisiti dell'utente.

Supponendo di disporre dei test di unità e integrazione appropriati che corrispondono ai requisiti e ai criteri di accettazione ben definiti e ai piani di test di accettazione, allora tutto il sistema viene testato. Altri aspetti del test: test del fumo, test di regressione e così via, sono semplicemente un sottocampionamento appropriato dell'unità, dell'integrazione e dei test di accettazione.

TDD is a robust way of designing software components (“units”) interactively so that their behaviour is specified through unit tests

Quella citazione particolare manca anche qualcosa. Come mi è stato insegnato, TDD non riguarda solo i test unitari, ma innanzitutto lo sviluppo di tutti i test. Ciò include non solo i test unitari, ma anche i necessari test di accettazione e integrazione.