Μια "μικρή" θύελλα έχει ξεσπάσει την τελευταία εβδομάδα με αφορμή τις οδηγίες της Microsoft σχετικά με το Test-Driven Development. Ο λόγος? Ότι αυτό που περιγράφεται στο άρθρο ως Test-Driven Development απλά δεν είναι. Για την ακρίβεια, είναι το ακριβώς αντίθετο.
Όταν χρησιμοποιεί κανείς Test-Driven Development, πρώτα γράφει μικρά και εύκολα test με τον κώδικα όπως θα ήθελε να τρέξει για να υλοποιήσει ένα μικρό κομμάτι των απαιτήσεων, και μετά γράφει τις κλάσεις, τις μεθόδους και τον κώδικα από πίσω τους που θα υλοποιήσει τη λειτουργία. Μόλις περάσει το ένα τεστ, προχωράς στο επόμενο. Έτσι καταλαβαίνεις σταδιακά και τί δουλεύει ή όχι, πόσο περίπλοκα είναι πραγματικά η εφαρμογή και δημιουργείς σταδιακά την κατάλληλη σχεδίαση
Το επίμαχο άρθρο όμως προτείνει να δημιουργηθούν από την αρχή οι κλάσεις και οι μέθοδοι, και μετά να δημιουργηθούν αυτόματα τα τεστ από τον κώδικα. Τον κώδικα μέσα στα τεστ βέβαια τον γράφουμε μόνοι μας. Απαιτεί ουσιαστικά να σχεδιαστεί όλη η εφαρμογή εκ των προτέρων, πριν καλά-καλά καταλάβει κανείς τί χρειάζεται, ενώ τα τεστ θα πρέπει να γραφτούν με τη μία αντί σταδιακά.
Το συγκεκριμμένο άρθρο έχει προκαλέσει θύελλα αντιδράσεων ενώ η αξιολόγηση του είναι σταθερά αρνητική, με πάνω από 300 αναγνώστες να το έχουν ήδη βαθμολογίσει με 1/9 (0 δεν υπάρχει). Το πρόβλημα είναι ότι πολύς κόσμος θα το διαβάσει και θα νομίσει ότι αυτός είναι ο σωστός τρόπος να κάνει Test-Driven Development και είτε θα το εγκαταλείψει τρομοκρατημένος, ή θα το εφαρμόσει εντελώς λάθος.
Αξίζει να διαβάσει κανείς τί έχει ήδη γραφτεί για το θέμα, καθώς μερικά από τα σχόλια είναι αρκετά βαρειά (διαβάστε Ron Jeffries στο τέλος):
Sam Gentile
The Microsoft Guidelines for TDD are creating quite a storm of protest from people in the Agile community for very good reason. They don't at all describe Test-Driven Development (TDD). They got it all wrong.
Roy Osherove
You''ll find that generating many test method stubs is usually the least helpful thing to do in any unit-testing scenariolet alone test-driven development, yet Microsoft toots it as one of the enabling features for TDD in Team System. That's an insult to the reader's intelligence and frankly, annoys me a lot.
I do see good things in VSTS. The fact that it brings Unit Tests to the mainstream tools of .NET developers is huge. Java developers have had this support in their IDEs for years, and now that it's coming to Microsoft, some things will definitely change for the better. but this is just a marketing guy or an intern trying to point a pig with lipstick. Don't sell something it's not. You're embarrassing me and all the other folks who actually try to talk people into doing TDD, and will want to use VSTS to do it.
Larkware
"Microsoft really needs to do a couple of things here. First, they need to yank the offending content from MSDN before any more people notice how stupid they look. Second, some of the more prominent Microsoft agile bloggers need to step up to the plate to explain what they're doing to evangelize within the company so that this sort of thing is less likely to happen again in the future."
Scott Bellware
"Rather than shape up Visual Studio to be amenable to Test-Driven Development, and in its ignorance of the nature of Test-Driven Development, Microsoft’s marketing people have simply tried to snow job the developer community into swallowing a wholly different definition of Test-Driven Development. And the very text outlining Microsoft’s understanding of Test-Driven Development betrays its almost complete ignorance of why Test-Driven Development is effective and why it is practiced in the way that it is.
So, this is for the folks at MSDN. Listen up… you’ve already embarrassed yourself once, and you’ve embarrassed your insider and MVP communities by association this time as well..
Ο Scott Bellware μάλιστα έχει και αναφορές στα σχόλια γνωστών ονομάτων στο χώρο του TDD, μεταξύ των οποίων του Robert Martin και του Ron Jeffries
Robert Martin:
Microsoft should pull these guidelines and try to figure out some way that the tool might actually support TDD. Redefining TDD as some kind of waterfall, just because their tool supports it that way, is not very helpful to the industry; and most programmers are all to clearly aware of this. If Microsoft would like to win the hearts and minds of more developers, they'd better try to figure out where the industry is actually going, rather than trying to drag the industry into it's tool. IMHO they should look very carefully at Eclipse, and IntelliJ -- especially IntelliJ.
Bottom line: We don't need tools that help us do waterfall better. We don't need vacuous process guidlines with 14 linear steps describing something that is not TDD while claiming otherwise. We don't need to be force fed Visual Studio. What we need from Microsoft is for them to stop talking and listen.
Michael Feathers:
The style of TDD described in the guidelines would have us jump ahead and write five, ten, maybe twenty test cases before getting the first one to pass. You can do that, but it's like putting on a set of blinders. When you don't have to formulate the next test case right after passing the last one, there isn't much chance to think about improvements. Worse, there is a disincentive to thinking about them: if you find any, you have to delete all of the speculation you've hardcoded in the tests and interfaces you created in advance.
Right now, I hope that MS revisits their guidelines. Yes, they have a tool that generates test stubs, but using it for TDD looks counter-productive. Adding stubs to legacy code? That would be great, but getting in the way of the feedback cycle? Bad. Bad. Bad.
Ron Jeffries:
The original article, at msdn2.microsoft.com/en-us/library/ms182521.aspx, describes TDD as a process where you get all your requirements understood, then define all your tests, then design an object's full interface, implement the tests, and make them work. It then goes on to explain how all these cool features in VSTS help with this "TDD" process.
The features might be good, but the process described is not TDD, nor a reasonable variation thereof. Test-Driven Development was clearly defined by Kent Beck, and has been described by others, such as Dave Astels, and even myself. It is a process where the tests are written one at a time (though one might make note of some possible tests for the future), and the tests are used to help define the design and develop the code. The Microsoft version of TDD is indistinguishable from a single-object waterfall model, to a first approximation.
Someone more paranoid than I am might conclude that Microsoft is intentionally trying to co-opt a perfectly good practice, pervert it, and tie it into mandatory use of their tools, which are, at this writing, about half as good as what's available in Open Source and commercial plug-ins for Visual Studio. I prefer to assume that it's just ignorance on their part, but I'm prepared to change my mind.
The article is shameful. If it isn't intentionally malicious, it is at least ignorant and ill-conceived. It should be taken down and replaced with something that correctly reflects industry usage of the TDD terminology.
Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos