Test guidati dalla progettazione: Test più intelligenti, non più difficili

Recensioni dei lettori

Le recensioni di “Design Driven Testing: Test Smarter, Not Harder” sono contrastanti, con alcuni lettori che ne lodano le intuizioni sulla metodologia di testing e altri che lo criticano per essere un attacco di parte al Test Driven Development (TDD). Mentre alcuni hanno trovato il libro una risorsa utile che fornisce chiarezza ed esempi pratici, altri ritengono che manchi di sostanza, che sia promozionale di altri lavori degli autori e che contenga imprecisioni sul TDD.

I lettori hanno apprezzato la nuova prospettiva del libro sulle metodologie di testing, in particolare l'enfasi posta sul design-driven testing (DDT) rispetto al tradizionale test-driven development (TDD). Lo stile di scrittura è stato notato per essere chiaro e conciso, con esempi pratici che aiutano a comprendere i concetti. Alcuni l'hanno trovato una risorsa utile per migliorare le tecniche di testing nello sviluppo del software.

I critici sostengono che il libro respinge il TDD senza una comprensione adeguata ed è pieno di imprecisioni sulle metodologie agili. Alcuni ritengono che si tratti di materiale promozionale per i prodotti degli autori, in particolare ICONIX, piuttosto che di un'esplorazione corretta della TDD. Inoltre, il libro presuppone una certa familiarità con alcuni strumenti e lavori precedenti, il che potrebbe limitarne l'accessibilità a un pubblico più ampio. Diversi recensori hanno descritto il contenuto come ripetitivo e asciutto.

(basato su 11 recensioni dei lettori)

Titolo originale:

Design Driven Testing: Test Smarter, Not Harder

Contenuto del libro:

In questo capitolo abbiamo illustrato come guidare i test unitari a partire dal progetto del software, identificando gli scenari di test in modo sistematico per garantire che il codice sia coperto in tutti i punti giusti. Abbiamo anche illustrato l'uso di "servizi stunt" e di oggetti mock per isolare il codice da testare; infine, abbiamo discusso di come guidare i test unitari più in profondità nel codice algoritmico che può beneficiare di test a grana più fine.

Esiste un modo per ottenere il 95% dei benefici dei test unitari completi che abbiamo fatto in questo capitolo con un numero significativamente inferiore di test? Nel prossimo capitolo mostreremo come fare esattamente questo con i test dei controllori. Come si vedrà, i test unitari hanno il loro posto, ma i test dei controllori possono spesso rappresentare un approccio più intelligente e strutturato al test delle applicazioni. 136 C A P I T O R E 6? Progettazione concettuale e test dei controllori Come si è visto nel Capitolo 5, i test unitari non devono necessariamente coprire in modo esaustivo ogni singola riga di codice, o addirittura ogni singolo metodo, con i test.

Esiste una legge di rendimenti decrescenti - e di difficoltà crescente - quando si spinge il percentile di copertura del codice sempre più in alto. Facendo un passo indietro e guardando il progetto su una scala più ampia, è possibile individuare le aree chiave del codice che fungono da punti di ingresso/uscita e concentrare i test su quelle aree.