testing - italiano - test driven development pdf




Perché dovrei praticare Test Driven Development e come dovrei iniziare? (4)

Molte persone parlano di scrivere test per il loro codice prima di iniziare a scrivere il loro codice. Questa pratica è generalmente nota come Test Driven Development o TDD in breve. Quali benefici ottengo dallo scrivere software in questo modo? Come iniziare con questa pratica?



Ci sono molti vantaggi:

  • Ottieni un riscontro immediato se il tuo codice funziona, così puoi trovare i bug più velocemente
  • Vedendo il test passare da rosso a verde, sai che hai sia un test di regressione funzionante, sia un codice funzionante
  • Ottieni confidenza nel rifattorizzare il codice esistente, il che significa che puoi ripulire il codice senza preoccuparti di cosa potrebbe rompersi
  • Alla fine hai una suite di test di regressione che possono essere eseguiti durante le build automatiche per darti maggiore sicurezza che il tuo codebase sia solido

Il modo migliore per iniziare è iniziare. C'è un grande libro di Kent Beck su Test Driven Development. Inizia semplicemente con un nuovo codice, non preoccuparti del vecchio codice ... ogni volta che ritieni di dover refactoring del codice, scrivi un test per la funzionalità esistente, quindi ridefinisci il codice e assicurati che i test rimangano verdi. Inoltre, leggi questo fantastico articolo .


Potresti lavorare in un ambiente agile o a cascata. Forse hai procedure ben definite che sono state testate in battaglia in anni di duro lavoro, o forse hai appena iniziato la tua start-up. Non importa quale fosse la situazione, probabilmente hai affrontato almeno uno, se non di più, dei seguenti dolori, problemi o cause di parto non riuscito:

  • Una parte del tuo team viene tenuta fuori dal giro durante la creazione di requisiti, specifiche o user story
  • La maggior parte, se non tutti, dei tuoi test sono manuali o non hai affatto test
  • Anche se hai eseguito test automatici, non rilevano problemi reali
  • I test automatici vengono scritti ed eseguiti quando è troppo tardi per fornire un valore reale al progetto
  • C'è sempre qualcosa di più urgente di dedicare del tempo ai test
  • I team sono suddivisi tra test, sviluppo e reparti di analisi funzionale e spesso non sono sincronizzati
  • Incapacità di refactoring del codice a causa del timore che qualcosa venga rotto
  • Il costo di manutenzione è troppo alto
  • Il time-to-market è troppo grande
  • I clienti non sentono che ciò che è stato consegnato è ciò che hanno chiesto
  • La documentazione non è mai aggiornata
  • Hai paura di distribuire in produzione perché il risultato è sconosciuto
  • Spesso non è possibile distribuire in produzione perché i test di regressione richiedono troppo tempo per essere eseguiti
  • Il team impiega troppo tempo a cercare di capire che metodo o classe fanno

Lo sviluppo basato sui test non risolve magicamente tutti questi problemi. Invece, ci mette sulla strada verso la soluzione. Non esiste una pallottola d'argento, ma se c'è una pratica di sviluppo che può fare la differenza su così tanti livelli, questa pratica è TDD. Lo sviluppo basato sul test accelera il time-to-market, consente un più facile refactoring, aiuta a creare un design migliore e favorisce un accoppiamento più flessibile. Oltre ai vantaggi diretti, TDD è un prerequisito per molte altre pratiche (la consegna continua è una di queste). Design migliore, codice ben scritto, time-to-market più rapido, documentazione aggiornata e solida copertura dei test, sono alcuni dei risultati che otterrete applicando TDD.


Secondo me, la cosa più importante è che ti permette chiaramente di vedere se il tuo codice fa quello che dovrebbe. Questo può sembrare ovvio, ma è super facile sfuggire agli obiettivi originali, come ho scoperto in passato: p





tdd