Perché lo sviluppo guidato dai test manca da Joel's Test?

Lo sviluppo guidato dai test era praticamente sconosciuto prima che il libro di Kent Beck uscisse nel 2002, due anni dopo Joel ha scritto quel post. La domanda diventa allora perché Joel non ha aggiornato il suo test, o se TDD era stato meglio conosciuto nel 2000, l'avrebbe incluso tra i suoi criteri?

Credo che non lo farebbe, per la semplice ragione che l'importante è che tu abbia un processo ben definito, non i dettagli specifici di quel processo. È la stessa ragione per cui raccomanda il controllo della versione senza specificare uno specifico sistema di controllo della versione, o raccomanda di avere un database di bug senza raccomandare una marca specifica. I buoni team migliorano continuamente e si adattano e utilizzano strumenti e processi che si adattano bene alla loro particolare situazione in quel particolare momento. Per alcune squadre, ciò significa sicuramente TDD. Per le altre squadre, non così tanto. Se adotti TDD, assicurati che non sia fuori dalla mentalità culto .

Joel ha effettivamente affrontato questo in particolare in alcuni punti.

Ha spiegato che i test delle cose non sono in grado di cogliere un sacco di problemi importanti, in particolare quelli soggettivi come "l'interfaccia utente di questo software fa schifo?" Secondo lui, l'eccessivo affidamento sui test automatici di Microsoft è come siamo finiti con Windows Vista.

Ha scritto come, nella sua esperienza, i tipi di bug che gli utenti effettivamente trovano tendono a ricadere in due categorie: 1) quelli che appaiono nell'uso comune, che i programmatori avrebbero trovato se avessero eseguito il proprio codice prima di usarlo, o 2) casi limite così oscuri che nessuno avrebbe mai pensato di scrivere test per coprirli in primo luogo. Ha dichiarato che solo una piccolissima percentuale dei bug che lui e il suo team hanno risolto in FogBugz sono il genere di cose che il test unitario avrebbe catturato. (Non riesco a trovare l'articolo ora, ma se qualcuno sa quale intendo, sentiti libero di modificare il link qui.)

E ha scritto come può essere più problematico di quanto valga, specialmente quando il tuo progetto diventa un progetto molto grande con molti test unitari e poi cambi qualcosa (intenzionalmente) e finisci con un numero molto grande di test di unità spezzati. In particolare usa i problemi che l'unit test può causare come motivo per cui non ha aggiunto è il 13 ° punto del test di Joel, anche quando le persone suggeriscono che dovrebbe farlo.

Lo stesso Joel Spolsky ha risposto a questa domanda nel 2009 :

Joel: There's a debate over Test Driven Development... should you have unit tests for everything, that kind of stuff... a lot of people write to me, after reading The Joel Test, to say, "You should have a 13th thing on here: Unit Testing, 100% unit tests of all your code."

And that strikes me as being just a little bit too doctrinaire about something that you may not need. Like, the whole idea of agile programming is not to do things before you need them, but to page-fault them in as needed. I feel like automated testing of everything, a lot of times, is just not going to help you. In other words, you're going to write an awful lot of unit tests to insure that code that, really, is going to work, and you're definitely going to find out if it doesn't work [if you don't write the tests] does, actually still work, ... I don't know, I'm going to get such flame mail for this because I'm not expressing it that well. But, I feel like if a team really did have 100% code coverage of their unit tests, there'd be a couple of problems. One, they would have spent an awful lot of time writing unit tests, and they wouldn't necessarily be able to pay for that time in improved quality. I mean, they'd have some improved quality, and they'd have the ability to change things in their code with the confidence that they don't break anything, but that's it.

But the real problem with unit tests as I've discovered is that the type of changes that you tend to make as code evolves tend to break a constant percentage of your unit tests. Sometimes you will make a change to your code that, somehow, breaks 10% of your unit tests. Intentionally. Because you've changed the design of something... you've moved a menu, and now everything that relied on that menu being there... the menu is now elsewhere. And so all those tests now break. And you have to be able to go in and recreate those tests to reflect the new reality of the code.

So the end result is that, as your project gets bigger and bigger, if you really have a lot of unit tests, the amount of investment you'll have to make in maintaining those unit tests, keeping them up-to-date and keeping them passing, starts to become disproportional to the amount of benefit that you get out of them.

Nessuno, a parte Joel, potrebbe rispondere di sicuro. Ma possiamo provare alcune ragioni / osservazioni.

Prima di tutto, il test non è assente dal test di Joel

• I test sono menzionati due volte in 12 passaggi direttamente (10 e 12)
• L'esistenza di una build è uno dei primi punti. L'idea di avere una build è di avere la capacità di vedere se si rompono, quindi stiamo anche parlando dei test qui.

In secondo luogo, l'intera idea del test di Joel (a quanto ho capito) è di avere domande rapide, si-no. "Fai TDD?" non si adatta perfettamente (la risposta potrebbe essere: "alcuni di noi", "per quella parte del codice" o "facciamo test di unità".

In terzo luogo, penso che nessuno abbia detto che (anche Joel) quei punti in cui "gli unici vale la pena del tempo" (a proposito, "programmate" non sono su di esso), solo che quelle sono buone domande veloci a chiedi quando entri in contatto con un team di software, sia come futuro membro del team o anche come cliente - questa è una lista che ho dato ad alcune persone non tecniche intorno a me che cercavano indizi su quanto il loro dipartimento IT fosse buono / cattivo . Non è tutto, ma è davvero brutto battere in tre minuti.