tag:blogger.com,1999:blog-1697388841986104302.post6907858272983631843..comments2023-07-02T10:36:44.294-05:00Comments on Agile in a Flash: Why POUT (aka TAD) SucksAgileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-1697388841986104302.post-18232094354934078172010-06-03T15:06:06.876-05:002010-06-03T15:06:06.876-05:00Michael: nice.
Of course TDD is testing before, d...Michael: nice.<br /><br />Of course TDD is testing before, during, and after. It is indeed the "test only after" that we're vocally against. <br /><br />We find that the red-green-refactor cycle (test before and as you code, clean as and after you test) has had a profound effect on the code we write, and not merely in lower defect density. <br /><br />Some people call TDD unit tests "programmer tests" because they are of benefit to us primarily. TDD is sufficient to enable us to make steady progress and clean the code as we work. It may not be sufficient to other purposes.<br /><br />The app still has to be run and demonstrated, and there have to be acceptance tests, and there is that extremely human activity of exploratory testing, there needs to be performance testing and scalability testing. There are plenty of "ilities" remaining which require other testing.<br /><br />But I'm glad that testing professionals find TDD-ed code easier to work with. <br /><br />You mentioned "testing only before you've written the code" which is something I've never seen done. Would anyone really write all the tests first before coding? That sounds like big-design-up-front (BDUF) and I don't think it would work. Maybe you have references to people actually working that way. It would be new to me.<br /><br />TimAgileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-53945232950388798432010-06-03T10:50:17.615-05:002010-06-03T10:50:17.615-05:00Why would writing tests after generate any differe...<i>Why would writing tests after generate any different result from writing tests first?</i><br /><br />The answer is that your notions of risk, your test ideas, and all the problems that we'll encounter cannot all be anticipated in advance of writing the code. We will learn things as we write the code and after the code is written. These learnings lead to new risk ideas and new test ideas, things that make us curious about the behaviour of the program. "Okay, that's done. Hey... I wonder... what if...?"<br /><br /><i>I'm not arguing against TDD here.</i> I'm a tester. Programmers who use TDD provide me with more robust and more testable code. Thank you. I can spend more time getting better test coverage if I don't have to investigate and report on the kinds of problems that TDD helps to prevent. This is a Good Thing. I like the idea, and I wish more programmers would do it. <br /><br />Instead, of objecting to TDD or advocating only TAD, I'm cautioning that TDD is necessary but not sufficient for a program to be well tested. That is, testing <i>only</i> after you've written the code, and testing <i>only</i> before you've written the code <i>both</i> suck.<br /><br />---Michael B.Michael Bolton http://www.developsense.comhttps://www.blogger.com/profile/09027725699187903416noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-40940684430608052182009-07-28T10:31:39.435-05:002009-07-28T10:31:39.435-05:00@jeff: not a bad idea. We should come up with argu...@jeff: not a bad idea. We should come up with argument/however/however/therefore cards.Agileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-28447137771605933012009-02-11T10:01:00.000-06:002009-02-11T10:01:00.000-06:00Hey Tim--I kind of like the idea of having a categ...Hey Tim--I kind of like the idea of having a category of "argument cards," things that I might carry to be able to refute common points that someone might come up with.Jeff Langrhttps://www.blogger.com/profile/10499693020049210645noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-49932887284515131522009-02-09T15:25:00.000-06:002009-02-09T15:25:00.000-06:00TAD sucks because you only start testing after you...TAD sucks because you only start testing after you've written code that's hard to test. <BR/><BR/>TAD sucks because it tends to duplicate whatever was in the AT in a different language. <BR/><BR/>TAD sucks because it is hard, slow, and unrewarding. I can't come up with anything worse to say about a coding practice.<BR/><BR/>TDD on the other hand, works like a son-of-a-gun!Agileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-6969035228248051392009-02-09T13:14:00.000-06:002009-02-09T13:14:00.000-06:00Not all cards are intended for ultimate publicatio...Not all cards are intended for ultimate publication! Tim and I will have a bit of fun with some of these, which may help stimulate other ideas or help improve the content of existing cards. Please chime in with your opinions.Jeff Langrhttps://www.blogger.com/profile/10499693020049210645noreply@blogger.com