Comments on: The (Some) Fallacies of Test First Development http://billchapman.net/?p=128 bill.is_a?('Geek') => true Wed, 18 Aug 2010 21:51:23 +0000 http://wordpress.org/?v=2.8.5 hourly 1 By: admin http://billchapman.net/?p=128&cpage=1#comment-115 admin Fri, 13 Nov 2009 00:01:16 +0000 http://billchapman.net/?p=128#comment-115 The post was a originally a response to several recent situations where I had to deal with people who are so dogmatic about their way of doing things that its almost useless to discuss it with them. In this case I understand testing well and I am not here to debate my abilities or understanding of TDD. I never said that TDD is ineffective when applied correctly and if you read the article I never personally said TDD had anything to do with unit testing or code coverage, I said that people have used those items as arguments in favor of TDD. The fact of the matter is that it doesn't work for everybody or every team. I write my tests first often, sometimes it works for me. But I refuse to require it of my team or of myself as it is not always the right way to approach a problem. As far as how I hope to accomplish low coupling and high cohesion in code design and development. I find that good, experienced developers (of whom there may be shortage of in this industry) do not have a problem achieving these items without TDD and that inexperienced developers struggle with it whether they are are testing first or not. There is plenty of good code that was written before everyone jumped on the TDD bandwagon. Testing first in and of itself does nothing to ensure that your code is decoupled, no matter what it is still all about how well you can model the process mentally. Some are better than others at that process and TDD will help many people but that doesn't mean it helps everybody. Your point here seems to be in the same vein as quetions like "How did anyone ever keep in touch before email?" . Sure it was harder to maintain communication for some people but others managed to do it just fine. Thank you for taking the time to leave a comment here. I have had an overwhelmingly positive response to this post from others and two thirds of my reddit votes were positive. In this case I'm quite sure the naysayers are in the minority but this does not mean that I give less value to a contrary opinion. Debating testing methodologies seems akin to debating religion these days and there really isn't a tangible best answer. All that matters is what works for you and your team. I had some things to say about testing and a colleague who agreed with my points thought I should put it on Reddit, it was my first submission there and I had no idea I'd get so many responses. I have learned a lot from those responses and I guess that was the real point of the post. The post was a originally a response to several recent situations where I had to deal with people who are so dogmatic about their way of doing things that its almost useless to discuss it with them. In this case I understand testing well and I am not here to debate my abilities or understanding of TDD. I never said that TDD is ineffective when applied correctly and if you read the article I never personally said TDD had anything to do with unit testing or code coverage, I said that people have used those items as arguments in favor of TDD. The fact of the matter is that it doesn’t work for everybody or every team. I write my tests first often, sometimes it works for me. But I refuse to require it of my team or of myself as it is not always the right way to approach a problem.

As far as how I hope to accomplish low coupling and high cohesion in code design and development. I find that good, experienced developers (of whom there may be shortage of in this industry) do not have a problem achieving these items without TDD and that inexperienced developers struggle with it whether they are are testing first or not. There is plenty of good code that was written before everyone jumped on the TDD bandwagon.

Testing first in and of itself does nothing to ensure that your code is decoupled, no matter what it is still all about how well you can model the process mentally. Some are better than others at that process and TDD will help many people but that doesn’t mean it helps everybody.
Your point here seems to be in the same vein as quetions like “How did anyone ever keep in touch before email?” . Sure it was harder to maintain communication for some people but others managed to do it just fine.

Thank you for taking the time to leave a comment here. I have had an overwhelmingly positive response to this post from others and two thirds of my reddit votes were positive. In this case I’m quite sure the naysayers are in the minority but this does not mean that I give less value to a contrary opinion.

Debating testing methodologies seems akin to debating religion these days and there really isn’t a tangible best answer. All that matters is what works for you and your team. I had some things to say about testing and a colleague who agreed with my points thought I should put it on Reddit, it was my first submission there and I had no idea I’d get so many responses. I have learned a lot from those responses and I guess that was the real point of the post.

]]> By: Christian http://billchapman.net/?p=128&cpage=1#comment-113 Christian Thu, 12 Nov 2009 18:51:12 +0000 http://billchapman.net/?p=128#comment-113 Most of this sounds like a strawman to me. I suppose if someone is perpetuating these fallacies, they really don't know what they are talking about. As mentioned by a few previous commenters, TDD is not about Unit Testing, or code coverage at all. It's purely a design process, that makes it much easier to create a loosely coupled, highly cohesive design. Do you think TDD practioners never write unit tests afterwards? I am really not sure what you hope to accomplish with a post like this. Are you purposefully misrepresenting TDD/BDD to be contrarian? If you think your representation of TDD is fair, what design process do you suggest developers follow to accomplish, high cohesion, and low coupling? Most of this sounds like a strawman to me. I suppose if someone is perpetuating these fallacies, they really don’t know what they are talking about.

As mentioned by a few previous commenters, TDD is not about Unit Testing, or code coverage at all. It’s purely a design process, that makes it much easier to create a loosely coupled, highly cohesive design. Do you think TDD practioners never write unit tests afterwards?

I am really not sure what you hope to accomplish with a post like this. Are you purposefully misrepresenting TDD/BDD to be contrarian? If you think your representation of TDD is fair, what design process do you suggest developers follow to accomplish, high cohesion, and low coupling?

]]> By: Chris http://billchapman.net/?p=128&cpage=1#comment-112 Chris Sun, 08 Nov 2009 23:01:32 +0000 http://billchapman.net/?p=128#comment-112 If you write tests to verify that your code works properly, and to guard against regression, then perhaps you would benefit by not writing unit tests at all? Regression tests / functional tests do a much better job of demonstrating that your code actually does what it is supposed to do. In an integrated, end to end way, your unit tests give very little guarantees or confidence. If unit tests are not driving your design, because you don't write code that way, then why create such fine grained tests at all? I am one of those zealots who does the whole BDD thing, because I find that when I write code that way, it tends to evolve from understanding what the interface should be before thinking about how the code should solve the problem. I tend to work on applications that grow and change regularly in production, and have found that when I write code using TDD, that I find it easier to keep the code clean and easy to maintain. If your mileage varies because you have superior design skills, that's okay. Though it may make it harder for others working on the same code base who don't share the same talent. Even with TDD, I find that I still need to add separate acceptance tests, often after I've written the code, because unit tests don't prove that your application works. That's not what they are for. You can have a high percentage of code coverage, with all your unit tests passing, but still have an application that won't even start. If you write tests to verify that your code works properly, and to guard against regression, then perhaps you would benefit by not writing unit tests at all? Regression tests / functional tests do a much better job of demonstrating that your code actually does what it is supposed to do. In an integrated, end to end way, your unit tests give very little guarantees or confidence. If unit tests are not driving your design, because you don't write code that way, then why create such fine grained tests at all?

I am one of those zealots who does the whole BDD thing, because I find that when I write code that way, it tends to evolve from understanding what the interface should be before thinking about how the code should solve the problem. I tend to work on applications that grow and change regularly in production, and have found that when I write code using TDD, that I find it easier to keep the code clean and easy to maintain. If your mileage varies because you have superior design skills, that's okay. Though it may make it harder for others working on the same code base who don't share the same talent.

Even with TDD, I find that I still need to add separate acceptance tests, often after I've written the code, because unit tests don't prove that your application works. That's not what they are for. You can have a high percentage of code coverage, with all your unit tests passing, but still have an application that won't even start.

]]> By: Paul Keeble http://billchapman.net/?p=128&cpage=1#comment-110 Paul Keeble Sun, 08 Nov 2009 15:56:14 +0000 http://billchapman.net/?p=128#comment-110 The very fact your writing unit tests at all is a good sign your on your way to being test infected. But the whole point of Unit testing is not to achieve coverage of the code or to functionally test it, that is a side effect of the approach. Its a useful side effect as it contributes to maintenance but doing activities that may/should save you time in the future is a recipe for not doing those things. TDD on the other hand is a design process. By focussing on external factors for a classes/modules we can assign clear responsibilities. Writing the test first allows a free form way to produce a clean API with clear and obvious responsibilities for methods, and to signify the relationships between them. Its quick to prototype the look of various possible approaches and see how it looks in practice and any edge cases that look bad. In the process you produce some executing tests and can use them to confirm the behaviour. You don't get complete functional or line coverage, but what you do get is a more obvious design. How far you go with that initial step of tests to determine the functional needs of the system is up to experience but its always useful to do it. TDD is about design, not about tests. Its an approach to producing an executable design. Everything else is a side effect with benefits. The very fact your writing unit tests at all is a good sign your on your way to being test infected. But the whole point of Unit testing is not to achieve coverage of the code or to functionally test it, that is a side effect of the approach. Its a useful side effect as it contributes to maintenance but doing activities that may/should save you time in the future is a recipe for not doing those things.

TDD on the other hand is a design process. By focussing on external factors for a classes/modules we can assign clear responsibilities. Writing the test first allows a free form way to produce a clean API with clear and obvious responsibilities for methods, and to signify the relationships between them. Its quick to prototype the look of various possible approaches and see how it looks in practice and any edge cases that look bad. In the process you produce some executing tests and can use them to confirm the behaviour. You don't get complete functional or line coverage, but what you do get is a more obvious design. How far you go with that initial step of tests to determine the functional needs of the system is up to experience but its always useful to do it.

TDD is about design, not about tests. Its an approach to producing an executable design. Everything else is a side effect with benefits.

]]> By: james http://billchapman.net/?p=128&cpage=1#comment-109 james Sun, 08 Nov 2009 15:36:04 +0000 http://billchapman.net/?p=128#comment-109 > TDD/BDD is a skill that takes work, like any other. It's not like you start doing it and suddenly it's all rainbows and puppies. Why don't you spend that time on honing your design, algorithm, and problem solving skills? How is TDD/BDD going to help you when you have too many data to store in memory? How is TDD/BDD gonna help you when your ranking algorithm is taking 20 years to run? The last 30 years of software engineering people have been building databases, kernels, web-browsers, search engines, word processors fine without the TDD/BDD. What large and complex software system have been done using TDD lately in your lifetime? > TDD/BDD is a skill that takes work, like any other. It's not like you start doing it and suddenly it's all rainbows and puppies.

Why don't you spend that time on honing your design, algorithm, and problem solving skills? How is TDD/BDD going to help you when you have too many data to store in memory? How is TDD/BDD gonna help you when your ranking algorithm is taking 20 years to run?

The last 30 years of software engineering people have been building databases, kernels, web-browsers, search engines, word processors fine without the TDD/BDD. What large and complex software system have been done using TDD lately in your lifetime?

]]> By: noob http://billchapman.net/?p=128&cpage=1#comment-108 noob Sun, 08 Nov 2009 15:30:53 +0000 http://billchapman.net/?p=128#comment-108 @asd No. Experience and competency in design skill drive good API design, unless you are suggesting that TDD replaces design skills. @asd

No. Experience and competency in design skill drive good API design, unless you are suggesting that TDD replaces design skills.

]]> By: tjstankus http://billchapman.net/?p=128&cpage=1#comment-107 tjstankus Sun, 08 Nov 2009 13:43:00 +0000 http://billchapman.net/?p=128#comment-107 I actually think regression and verification are secondary purposes of test-driving code, a nice side-effect if you will. The primary purpose is producing more modular, understandable code. It's actually pretty tough to write a big pile of junk when you're being vigilant about test-driving. But I agree with you that TDD/BDD often adds unnecessary overhead when you're writing a prototype or proof-of-concept. TDD/BDD is a skill that takes work, like any other. It's not like you start doing it and suddenly it's all rainbows and puppies. It's painful and often slower, especially at first. All that said, I'm anti-dogma of any kind. Do what works for you. But know that TDD/BDD is not a magic light switch. It's gonna take time and work to get into the groove of it and become test-infected. I actually think regression and verification are secondary purposes of test-driving code, a nice side-effect if you will. The primary purpose is producing more modular, understandable code. It's actually pretty tough to write a big pile of junk when you're being vigilant about test-driving. But I agree with you that TDD/BDD often adds unnecessary overhead when you're writing a prototype or proof-of-concept.

TDD/BDD is a skill that takes work, like any other. It's not like you start doing it and suddenly it's all rainbows and puppies. It's painful and often slower, especially at first. All that said, I'm anti-dogma of any kind. Do what works for you. But know that TDD/BDD is not a magic light switch. It's gonna take time and work to get into the groove of it and become test-infected.

]]> By: Mazen Harake http://billchapman.net/?p=128&cpage=1#comment-106 Mazen Harake Sun, 08 Nov 2009 13:15:32 +0000 http://billchapman.net/?p=128#comment-106 ASD has a point but I still agree that Tests-First approach can suck time like a black hole. This is why you use psuedo-tests (or BDD). Funny enough I just wrote a blog post inline with yours. Check it out on my website link. Good arguments and points, more structured then mine are :D ASD has a point but I still agree that Tests-First approach can suck time like a black hole. This is why you use psuedo-tests (or BDD). Funny enough I just wrote a blog post inline with yours. Check it out on my website link. Good arguments and points, more structured then mine are :D

]]> By: asd http://billchapman.net/?p=128&cpage=1#comment-102 asd Sun, 08 Nov 2009 09:48:52 +0000 http://billchapman.net/?p=128#comment-102 "Unit testing serves two primary purposes." Three, actually. It can drive good API design, which is also the primary reason for writing tests first. "Unit testing serves two primary purposes."

Three, actually. It can drive good API design, which is also the primary reason for writing tests first.

]]> By: wayneeseguin http://billchapman.net/?p=128&cpage=1#comment-100 wayneeseguin Fri, 06 Nov 2009 19:36:00 +0000 http://billchapman.net/?p=128#comment-100 Great points Bill. I agree. Great points Bill. I agree.

]]>