I am not a proponent of TDD, but I will admit it has its place.\u00a0 And sometimes that place is not to use it, if the ultimate outcome will be of less value to the purpose of your software.<\/p>\n
Some reasons not to use TDD if the conditions warrant are:<\/p>\n
Use TDD if you are designing things that will benefit from it.\u00a0 Don’t if it will not.<\/p>\n
Object Design?<\/strong><\/p>\n TDD is a design pattern<\/span>, nothing more nothing less. While I have read a few books about TDD . . . I wonder, if true TDD people refuse to do up front object design.\u00a0 The methodology demands refactoring; and therefore following a Fowler idea that design will emerge, TDD practitioners must let objects emerge via refactoring.\u00a0 I mean, if they are TRULY doing TDD that’s what they would do.<\/p>\n Timeboxing is Agile’s David<\/strong><\/p>\n Its an interesting experiment to me; I do refactors and look for patterns.\u00a0 Then I pull them out if needed.\u00a0 Unless I come up with an estimate, and the project deadline and my manager says “no way jsut build it quick.”\u00a0 If you get on one of those projects using TDD (I was on one) a LOT of spaghetti code, with lots of test cases, gets written.\u00a0 Its about as bug proof as any other design style, that is, in those conditions TDD brings no value.<\/p>\n I think its a failure of a lot of Agile methods . . . ignores the reality of timeboxed projects.\u00a0 I have never worked on anything but; even being relatively young as my first computer class was on a Tandy PET and my first Basic program on a Vic 20.<\/p>\n A Use Case Where TDD would Fail – SUV Analogy I am actually using TDD do do some PL\/SQL conversion scripts right now.\u00a0\u00a0 I have to do it old school; and its taking time.\u00a0 Sometimes I just write the conditions.\u00a0 Since the scripts are throw away it we can’t store the unit tests in any sort of DB repository (but that would be great for stored procs etc.).\u00a0 I ran into a bit of a problem though . . . that writing code in TDD style sometimes causes more problems, depending on what you are trying to accomplish.<\/strong><\/em><\/p>\n Talking with a friend I came up with this real-life analogy of where TDD would fail.<\/p>\n TDD thinks it addresses quality but one thing it introduces is possible defects\u00a0 due to itself.\u00a0\u00a0 You have to make a judgement call based on your input factors of time, money, and risk as to whether its worth it to use this design pattern.\u00a0 For example, it would absolutely be worth it if designing space shuttle software.\u00a0 And, you had an unlimited budget.<\/p>\n But here’s an analogy where it would fail:<\/p>\n Suppose you are designing an SUV for extreme conditions.\u00a0 In one case, it’s a highly wet cool condition and in another, is a hot temperature condition.<\/p>\n The designers decide that testing of everything is very important.\u00a0 So they design in a hole in the engine that let’s you test sludge buildup in one of the cylinders:\u00a0 you unscrew something and get a physical look.\u00a0 Basically, a test has become part of the design.<\/p>\n But now the cylinder head is weakened because of the test.\u00a0 You have introduced a few failure conditions:\u00a0 possible weakened gasket that will let in contamination and cause engine failure.<\/p>\n It’s just a hypothetical but there are a ton of other things in our life just like this.\u00a0 Vehicles are easy . . . even now they are building all kinds of testing into the vehicles as part of the design (TDD): emissions, mixture, electric etc.\u00a0 The payoff is that this is very expensive to pay for, and also in increase costs due to specialized maintenance because your every day Joe or Jane auto mechanic can’t work on their own vehicle.\u00a0 Do vehicles really last any longer?\u00a0 I’d argue that they do not.\u00a0 TDD just extended the period between maintenance’s — i.e. you paid for your time up front instead of over time.<\/p>\n I’m not motivated enough to throw away a methodology if it may be useful, and TDD can teach us some things, but I guess the mantra is:\u00a0 “TDD: do it only if necessary.<\/strong><\/em>“<\/p>\n","protected":false},"excerpt":{"rendered":" I am not a proponent of TDD, but I will admit it has its place.\u00a0 And sometimes that place is not to use it, if the ultimate outcome will be of less value to the purpose of your software. Some reasons not to use TDD if the conditions warrant are: More code is higher risk […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[4,3],"tags":[],"_links":{"self":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/71"}],"collection":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=71"}],"version-history":[{"count":2,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/71\/revisions"}],"predecessor-version":[{"id":133,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/71\/revisions\/133"}],"wp:attachment":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=71"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=71"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=71"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n<\/strong><\/p>\n\n