my years of software development experience suggest that in practice it can't work.
L'hai provato? Dave e io abbiamo scritto il libro sulla base di molti anni di esperienza collettiva, sia di noi stessi che di altre persone senior in ThoughtWorks, facendo effettivamente le cose di cui discutiamo. Niente nel libro è speculativo. Tutto ciò di cui discutiamo è stato provato e testato anche su progetti grandi e distribuiti. Ma non ti suggeriamo di prenderlo sulla fede. Ovviamente dovresti provare tu stesso, e per favore scrivi ciò che trovi funziona e cosa no, incluso il contesto pertinente, in modo che gli altri possano imparare dalle tue esperienze.
La consegna continua ha un grande focus sui test automatici. Passiamo circa 1/3 del libro a parlarne. Lo facciamo perché l'alternativa - test manuale - è costosa e soggetta a errori, e in realtà non è un ottimo modo per creare software di alta qualità (come ha detto Deming, "Cessare la dipendenza dall'ispezione di massa per ottenere la qualità. il prodotto in primo luogo ")
Full test coverage is impossible. You have to put in lots of time -- and time is money -- for every little thing. This is valuable, but the time could be spent contributing to quality in other ways.
Ovviamente la copertura completa del test è impossibile, ma qual è l'alternativa: copertura del test zero? C'è un compromesso. In mezzo c'è una risposta corretta per il tuo progetto. Troviamo che in generale dovresti aspettarti di dedicare circa il 50% del tuo tempo alla creazione o al mantenimento di test automatizzati. Potrebbe sembrare costoso finché non consideri il costo di un test manuale completo e di correggere i bug che arrivano agli utenti.
Some things are hard to test automatically. E.g. GUI. Even Selenium won't tell you if your GUI is wonky.
Naturalmente. Controlla il quadrante del test di Brian Marick. È ancora necessario eseguire test esplorativi e test di usabilità manualmente. Ma è quello che dovresti usare per i tuoi costosi e preziosi esseri umani - non i test di regressione. La chiave è che è necessario mettere in atto una pipeline di distribuzione in modo che si limitino a eseguire costose convalide manuali contro build che hanno superato una suite completa di test automatizzati. In questo modo riduci sia la quantità di denaro speso per i test manuali, sia il numero di bug che riescono a eseguire test o produzione manuali (tempo in cui sono molto costosi da correggere). Le prove automatizzate fatte correttamente sono molto più economiche durante il ciclo di vita del prodotto, ma ovviamente è una spesa in conto capitale che si ammortizza nel tempo.
Database access is hard to test without bulky fixtures, and even that won't cover weird corner cases in your data storage. Likewise security and many other things. Only business-layer code is effectively unit-testable.
L'accesso al database è testato implicitamente dai test di accettazione funzionale basati su scenari end-to-end. La sicurezza richiederà una combinazione di test automatici e manuali - test di penetrazione automatizzati e analisi statiche per trovare (ad es.) Sovraccarichi del buffer.
Even in the business layer, most code out there is not simple functions whose arguments and return values can be easily isolated for test purposes. You can spend lots of time building mock objects, which might not correspond to the real implementations.
Naturalmente i test automatici sono costosi se si costruiscono male il software e i test. Consiglio vivamente di controllare il libro "software orientato agli oggetti in crescita, guidato dai test" per capire come farlo nel modo giusto affinché i test e il codice siano mantenibili nel tempo.
Integration/functional tests supplement unit tests, but these take a lot of time to run because they usually involve reinitializing the entire system on each test. (If you don't reinitialize, the test environment is inconsistent.)
Uno dei prodotti su cui ho lavorato ha una suite di 3.500 test di accettazione end-to-end che impiegano 18 ore per essere eseguito. Lo eseguiamo in parallelo su una griglia di 70 box e riceviamo feedback in 45m. Ancora più lungo dell'ideale, ed è per questo che lo gestiamo come la seconda fase della pipeline dopo che i test unitari sono stati eseguiti in pochi minuti, quindi non sprechiamo le risorse su una build che non abbiamo un livello base di fiducia in.
Refactoring or any other changes break lots of tests. You spend lots of time fixing them. If it's a matter of validating meaningful spec changes, that's fine, but often tests break because of meaningless low-level implementation details, not stuff that really provides important information. Often the tweaking is focused on reworking the internals of the test, not on truly checking the functionality that is being tested.
Se il tuo codice e i test sono ben incapsulati e accoppiati liberamente, il refactoring non interromperà molti test. Nel nostro libro descriviamo come fare la stessa cosa anche per i test funzionali. Se i test di accettazione si interrompono, è un segno che manchi uno o più test unitari, quindi parte del CD implica il miglioramento costante della copertura del test per cercare e trovare bug in precedenza nel processo di consegna in cui i test sono più a grana fine e i bug sono meno costosi da risolvere.
Field reports on bugs cannot easily be matched with the precise micro-version of the code.
Se stai testando e rilasciando più frequentemente (parte del punto del CD), allora è relativamente semplice per identificare la modifica che ha causato il bug. L'intero punto del CD è ottimizzare il ciclo di feedback in modo da poter identificare i bug il prima possibile dopo averli controllati per il controllo della versione - e in effetti, preferibilmente prima di essere registrati (motivo per cui eseguiamo i test di compilazione e unità prima del check-in).