5 ms·

The Great Benefit of Test Driven Development Nobody Talks About

15 points by boyter 16y ago

orangecat 16y ago
Unit testing is good, but I disagree with that reasoning. All else being equal, less code is better.
- apu 16y ago
  Yeah this is completely backwards to me -- do you want the illusion of progress? Or progress? Often they are mutually incompatible.
  - boyter 16y ago
    Just out of curiosity how are more tests (assuming they are useful tests) the illusion of progress? They provide value if they are well written, so they are progress are they not?
    - compay 16y ago
      Tests are of course very important, but when the coder begins to fetishize testing and write tests for the sake of writing tests, rather than to help pursue the project's goal, then it becomes a problem. I've been guilty of this earlier in my career and have seen quite a few other people do it too.
      - walkon 16y ago
        That's not a problem with the methodology, but with the person trying to practice it.
        deleted 16y ago
        [deleted]
        compay 16y ago
        Yeah, that was pretty much my point.
      - mkramlich 16y ago
        fetish -- that's a brilliant word for it. that does seem to accurately describe the vibe I've gotten from some developers when they talk about unit testing and TDD. fetish.
      - mistermann 16y ago
        > Tests are of course very important, but when the coder begins to fetishize testing and write tests for the sake of writing tests, rather than to help pursue the project's goal, then it becomes a problem. I've been guilty of this earlier in my career and have seen quite a few other people do it too. Any chance you could expand on this, especially the part about "I've been guilty of this earlier in my career". I am interested in TDD because so many people are such huge advocates of it (although I've seen many people being huge advocates of all sorts of things over the years), and I have an open mind, but this article does nothing to convince me, in fact is reinforces my skepticism. "The feeling of productivity because you are writing lots of code." Never mind if that code is useful, as long as it makes you "feel good". I'm open to being convinced, but I honestly don't have to spend a lot of time fixing and chasing down bugs in my code, and when I do, I can't imagine the wildly obscure and diverse tests I'd have to have written to actually catch them. I've asked this before...if anyone has a genuinely convincing article advocating TDD for the uninformed, I'd love to read it. The typical response to this is read x, y z book and it will make sense. My response is, I've been writing software for 15+ years, if you have something to sell me, do I have to buy your book to get the idea? I'm willing to meet you halfway, but TDD advocates don't seem to have the same mindset.
        compay 16y ago
        Simply put, when I first heard about TDD I got very excited and made the mistakes you would expect a well-intentioned but uninformed person would make: spending WAY too much time worrying about how to structure my tests correctly, which sometimes distracted me from the "real" problem at hand. At this point I would certainly not consider myself a great expert on testing, but I think I've acquired a bit more intuition on what and how to test things. I don't usually work in a strictly "test first" manner because often times it's easier for me to "sketch" out a few classes and go through a couple attempts at organizing things before I find an approach that works for me. In these cases, testing first is a pain in the butt. Other times, for example if I'm implementing some kind of tricky data filter, writing the tests first helps me think about the possible problems I might have to deal with in my implementation. In general though, my projects usually end up with close to 100% code coverage, even if some of the tests are not very granular. Throughout the lifecycle of the code I maintain, I add tests when fixing bugs to avoid regressions. The tests that I write obviously don't catch every bug, but they do usually stop me from making embarrassing, silly mistakes which I think covers a pretty significant percentage of bugs in general. I don't usually have to worry about breaking things when refactoring or adding new features, which is a great feeling that I pretty much never felt in either my "no testing" or "way too much testing" phases. So basically I have a very pragmatic attitude towards testing which I think would be non-threatening to a skeptic like yourself. :-) Part of the problem is that you might be letting yourself get turned off to valuable and useful techniques, not because of the techniques themselves, but the way in which they are being presented to you. But at the end of the day, you have to find whatever works best for you to make the best code you can, and don't worry about what other people think.
- boyter 16y ago
  Totally agree. Less code is good which is what you get with TDD in the application itself. But you do end up with a pile of tests which are code. What I see this is as you plug straight into the positive reinforcement part of your brain where you reward yourself over time then have a big reward at the end. Thats the biggest advantage that TDD gives you because it makes coding addictive like games can become.
  - techiferous 16y ago
    Yes, TDD is like drugs. Pretty soon you're doing it just for the hit and not to support your business goals... ;)
grandalf 16y ago
So by that logic is it more pleasing to have a bigger test suite than a smaller one? I'd argue that a test suite should be as small as possible to test the critical areas of the app, at least until the app ships, and then new tests should be added as the app takes a more definite shape, etc. How much fun is it to refactor a test suite b/c the product changed substantially and you are now mired in the cognitive dissonance of a very un-agile (slow) change or in a bunch of broken tests.
- boyter 16y ago
  Wouldn't that indicate that you have written bad tests to begin with? My personal experience is that if you have followed TDD to the letter then breaking tests are a good thing. If however your tests are breaking when you change unrelated things then you have brittle tests which are bad.
  - techiferous 16y ago
    Imagine an early version of a web app. An experiment. It's pre-product-market fit, even pre-problem-solution fit. Things are going to change...a lot. For example, you decided to rename "widgets" "fooblats". You have to change all of your tests that referred to widgets. This doesn't mean you have brittle tests; it means that what was being tested has changed. This early in the game a good testing strategy may be to write no tests. It all depends.
    - grandalf 16y ago
      This has been my experience. Tests can add some extra cognitive dissonance / friction when it comes to really being agile with your early concepts and approaches. Tests are great when you have a clear spec and you just have to keep the app reliable as you make minor iterations. Or when you're doing something so complex that it's hard to keep in your head at once (this is, I think, the most fun TDD). I think for most web apps a simple integration test that verifies that pages don't error and that basic forms work properly is going to be far more valuable than a bunch of code that tests very simple usages of underlying library code (which is sadly what many test suites I've read for web apps actually do).
d0m 16y ago
I don't agree with what I will say but: If you like so much writing code, you could, well, write code instead of tests. Programming example: while true: write tests write code run tests vs while true: write code write code write code Oh, you can also optimized that code with: while true write code. or (while true (write code)) Ok, I think I like writing code, not tests. (Oh, and btw, how do you test, (while true (write code)) ? )
mkramlich 16y ago
Of course, one can get the same feeling of success and progress and accomplishment by just writing the actual needed application code, without writing any test code. And you'd have the added bonus of producing more enduser perceivable features in the same block of time.
stretchwithme 16y ago
Good point. More code that does more work for you. To me, that's the coolest thing about programming. You create something and send it out into the world and it creates things too.
rlpb 16y ago
Tests are great. But a lot of my coding is experimental and not all of it ends up in production. Writing tests take time. If I wrote tests in advance, then a lot of experimenting wouldn't get done. So I often tend to write tests afterwards. My reward? When an experiment is a success and the new feature works. My second reward is when the feature ends up in production, which can only happen after tests are written.

15 points by boyter 16y ago

orangecat 16y ago

Unit testing is good, but I disagree with that reasoning. All else being equal, less code is better.

apu 16y ago
Yeah this is completely backwards to me -- do you want the illusion of progress? Or progress? Often they are mutually incompatible.
- boyter 16y ago
  Just out of curiosity how are more tests (assuming they are useful tests) the illusion of progress? They provide value if they are well written, so they are progress are they not?
  - compay 16y ago
    Tests are of course very important, but when the coder begins to fetishize testing and write tests for the sake of writing tests, rather than to help pursue the project's goal, then it becomes a problem. I've been guilty of this earlier in my career and have seen quite a few other people do it too.
    - walkon 16y ago
      That's not a problem with the methodology, but with the person trying to practice it.
      - deleted 16y ago
        [deleted]
      - compay 16y ago
        Yeah, that was pretty much my point.
    - mkramlich 16y ago
      fetish -- that's a brilliant word for it. that does seem to accurately describe the vibe I've gotten from some developers when they talk about unit testing and TDD. fetish.
    - mistermann 16y ago
      > Tests are of course very important, but when the coder begins to fetishize testing and write tests for the sake of writing tests, rather than to help pursue the project's goal, then it becomes a problem. I've been guilty of this earlier in my career and have seen quite a few other people do it too. Any chance you could expand on this, especially the part about "I've been guilty of this earlier in my career". I am interested in TDD because so many people are such huge advocates of it (although I've seen many people being huge advocates of all sorts of things over the years), and I have an open mind, but this article does nothing to convince me, in fact is reinforces my skepticism. "The feeling of productivity because you are writing lots of code." Never mind if that code is useful, as long as it makes you "feel good". I'm open to being convinced, but I honestly don't have to spend a lot of time fixing and chasing down bugs in my code, and when I do, I can't imagine the wildly obscure and diverse tests I'd have to have written to actually catch them. I've asked this before...if anyone has a genuinely convincing article advocating TDD for the uninformed, I'd love to read it. The typical response to this is read x, y z book and it will make sense. My response is, I've been writing software for 15+ years, if you have something to sell me, do I have to buy your book to get the idea? I'm willing to meet you halfway, but TDD advocates don't seem to have the same mindset.
      - compay 16y ago
        Simply put, when I first heard about TDD I got very excited and made the mistakes you would expect a well-intentioned but uninformed person would make: spending WAY too much time worrying about how to structure my tests correctly, which sometimes distracted me from the "real" problem at hand. At this point I would certainly not consider myself a great expert on testing, but I think I've acquired a bit more intuition on what and how to test things. I don't usually work in a strictly "test first" manner because often times it's easier for me to "sketch" out a few classes and go through a couple attempts at organizing things before I find an approach that works for me. In these cases, testing first is a pain in the butt. Other times, for example if I'm implementing some kind of tricky data filter, writing the tests first helps me think about the possible problems I might have to deal with in my implementation. In general though, my projects usually end up with close to 100% code coverage, even if some of the tests are not very granular. Throughout the lifecycle of the code I maintain, I add tests when fixing bugs to avoid regressions. The tests that I write obviously don't catch every bug, but they do usually stop me from making embarrassing, silly mistakes which I think covers a pretty significant percentage of bugs in general. I don't usually have to worry about breaking things when refactoring or adding new features, which is a great feeling that I pretty much never felt in either my "no testing" or "way too much testing" phases. So basically I have a very pragmatic attitude towards testing which I think would be non-threatening to a skeptic like yourself. :-) Part of the problem is that you might be letting yourself get turned off to valuable and useful techniques, not because of the techniques themselves, but the way in which they are being presented to you. But at the end of the day, you have to find whatever works best for you to make the best code you can, and don't worry about what other people think.
boyter 16y ago
Totally agree. Less code is good which is what you get with TDD in the application itself. But you do end up with a pile of tests which are code. What I see this is as you plug straight into the positive reinforcement part of your brain where you reward yourself over time then have a big reward at the end. Thats the biggest advantage that TDD gives you because it makes coding addictive like games can become.
- techiferous 16y ago
  Yes, TDD is like drugs. Pretty soon you're doing it just for the hit and not to support your business goals... ;)

grandalf 16y ago

So by that logic is it more pleasing to have a bigger test suite than a smaller one? I'd argue that a test suite should be as small as possible to test the critical areas of the app, at least until the app ships, and then new tests should be added as the app takes a more definite shape, etc. How much fun is it to refactor a test suite b/c the product changed substantially and you are now mired in the cognitive dissonance of a very un-agile (slow) change or in a bunch of broken tests.

boyter 16y ago
Wouldn't that indicate that you have written bad tests to begin with? My personal experience is that if you have followed TDD to the letter then breaking tests are a good thing. If however your tests are breaking when you change unrelated things then you have brittle tests which are bad.
- techiferous 16y ago
  Imagine an early version of a web app. An experiment. It's pre-product-market fit, even pre-problem-solution fit. Things are going to change...a lot. For example, you decided to rename "widgets" "fooblats". You have to change all of your tests that referred to widgets. This doesn't mean you have brittle tests; it means that what was being tested has changed. This early in the game a good testing strategy may be to write no tests. It all depends.
  - grandalf 16y ago
    This has been my experience. Tests can add some extra cognitive dissonance / friction when it comes to really being agile with your early concepts and approaches. Tests are great when you have a clear spec and you just have to keep the app reliable as you make minor iterations. Or when you're doing something so complex that it's hard to keep in your head at once (this is, I think, the most fun TDD). I think for most web apps a simple integration test that verifies that pages don't error and that basic forms work properly is going to be far more valuable than a bunch of code that tests very simple usages of underlying library code (which is sadly what many test suites I've read for web apps actually do).

d0m 16y ago

I don't agree with what I will say but: If you like so much writing code, you could, well, write code instead of tests. Programming example: while true: write tests write code run tests vs while true: write code write code write code Oh, you can also optimized that code with: while true write code. or (while true (write code)) Ok, I think I like writing code, not tests. (Oh, and btw, how do you test, (while true (write code)) ? )

mkramlich 16y ago

Of course, one can get the same feeling of success and progress and accomplishment by just writing the actual needed application code, without writing any test code. And you'd have the added bonus of producing more enduser perceivable features in the same block of time.

stretchwithme 16y ago

Good point. More code that does more work for you. To me, that's the coolest thing about programming. You create something and send it out into the world and it creates things too.

rlpb 16y ago

Tests are great. But a lot of my coding is experimental and not all of it ends up in production. Writing tests take time. If I wrote tests in advance, then a lot of experimenting wouldn't get done. So I often tend to write tests afterwards. My reward? When an experiment is a success and the new feature works. My second reward is when the feature ends up in production, which can only happen after tests are written.