Here is how Robert Martin puts it in his video "Clean Code Episode 6: TDD - Part 2" [1]:
"Spock: So now Uncle Bob, to gain this suite of tests, it is the tests that matter, not when we write them. Uncle Bob: balderdash! If you write your tests at the end they are not going to be complete and you are not going to trust them. This is just simple human nature. Humans consider things that come first to be important and things that come at the end to be less important and somehow optional. That's why they are at the end, so we can leave them out if we have to. When you write tests first, you trust those tests because every line of production code is tested. Tests come first because they are important perhaps than even the production code because the tests are what makes the production code flexible. Without the tests, the production code rots. Spock: I find myself in agreement. Humans almost always delay those things they consider optional or undesirable. If the tests are critical, the tests must come first." Martin is pretty hard-core about tests being first, and not just being written first. See his "Test First" post [2]. Here is the end of it: "The bottom line of all this is that we should consider our tests as being first. We already know we should write them first; but we should also clean them first, maintain them first, think of them first, and keep them first. We should give our tests the highest priority. That is what "Test First" really means. The Tests Come First!" [1] https://cleancoders.com/episode/clean-code-episode-6-p2/show [2] http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html Philip On Sunday, 23 February 2014 22:51:16 UTC, Philip Schwarz wrote: > > In "TDD leads to an architectural meltdown around iteration three" [1] you > say: “Tests first” or “tests last” is unimportant as long as there are > tests." > > In "TDD Triage" [1] Robert Martin has a section called "Well, if you are > going to write some tests afterwards, why not write all tests afterwards?". > Here is what it says: > > "Well, first, there’s the > George-Williams<http://web.archive.org/web/20120201002523/http://www.google.com/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2Fcollaboration.csc.ncsu.edu%2Flaurie%2FPapers%2FTDDpaperv8.pdf&ei=WoTMSvSXMYSqtgfDnMjrAQ&usg=AFQjCNHk6TJnNC32UGD8cN65EWGjoQkTBA&sig2=pbzOxiSB7_HAOoBTyDqetQ> > study, > which showed that teams who are instructed to write tests afterwards, don’t > write tests at all. Of course this is human nature. Once you have the code > “working” why write tests? Writing tests for code that you believe works > feels like a waste of time. > > But that can be countered with sheer discipline. The real reason to follow > The > Three Laws of > TDD<http://web.archive.org/web/20120201002523/http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd> > and > write your tests first is that it greatly enhances the chances that every > line and every decision is tested. > > Code coverage is a sneaky metric. It is quite possible to create extremely > high levels of coverage without a single assert. I don’t need to tell you > that coverage without asserts is less than meaningful. When you write tests > first, your assertion coverage is very high. When you write tests after, > you assertion coverage simply cannot be that high. Even the most dedicated > and determined developer will make some coding decisions that block later > testability. When you write the tests first, this simply cannot happen. > When you write the tests first every coding decision you make *must* support > testability. > > Clearly writing the tests first forces an extremely high degree of > compatibility between the tests and the code. Writing the tests first also > means that your first thoughts about the code are from the point of view of > a user, not an author; and that also has benefits. > > So, *all else being equal*, test-first is clearly better than test-after." > Philip > > On Friday, 21 February 2014 21:47:44 UTC, Cédric Beust ♔ wrote: >> >> Not a big fan for multiple reasons: >> >> - TDD introduces a lot of churn, especially in the early phases of your >> coding. If you're beginning to work on a problem from scratch, you will >> most likely throw one or two initial implementations before reaching >> something you feel is acceptable as a v1.0. Writing tests for any version >> prior to this one is a waste of time. >> >> - TDD encourages myopic design. You are more focused on writing your code >> so it can pass trivial unit tests than thinking about how your overall >> design will fit with the rest of the code base. >> >> - TDD has high friction. If you are very zealous with TDD, every minor >> change in the code base will cause you to update tests. I'm okay with a >> little bit of that (it's the purpose of tests) but not to the extent that >> TDD promotes. >> >> - It overly privileges unit tests over functional tests, and my default >> position is that functional tests are more important (if I have the time to >> write a functional or a unit test and just one, I'll always go for >> functional because these tests have a direct impact on users, as opposed to >> unit tests which are just a convenience for you, the developer). >> >> I have more (I wrote a bit of that in my book) but heading out for now. >> >> -- >> Cédric >> >> >> -- >> Cédric >> >> >> >> On Fri, Feb 21, 2014 at 1:08 PM, Rakesh <rakesh.m...@gmail.com> wrote: >> >>> Hi, >>> >>> **usual disclaimer about not looking to start a flame war** >>> >>> A friend of mine recently interviewed at a company for a position as an >>> iOS dev. >>> >>> The topic of TDD came up and my friend stated that she was a big fan. >>> >>> The interviewer on the other hand, said he wasn't and that the 'jury was >>> still out'. >>> >>> I'm curious, who is the 'jury'? >>> >>> As for myself, if i can join a team doing tdd or be in a position where >>> i can, i'm happy. >>> >>> This group is stocked with experienced devs so i'm not looking to >>> convert anyone, but surely by now, the nay sayers are in the decline? >>> >>> Thoughts? >>> >>> Rakesh >>> >>> Ps kevin, REALLY interested in your opinion. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Java Posse" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to javaposse+...@googlegroups.com. >>> To post to this group, send email to java...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/javaposse. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+unsubscr...@googlegroups.com. To post to this group, send email to javaposse@googlegroups.com. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/groups/opt_out.
