3 ms·

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

by 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.
  - torial 16y ago
    I've been following the TDD stuff as an outsider, and hands down the article that makes me consider it with the least skepticism is this one: http://blog.objectmentor.com/articles/2009/10/07/tdd-derangement-syndrome http://blog.objectmentor.com/articles/2009/10/07/tdd-derange... I'm sure there are issues w/ the various studies it cites, but it is the only one to actually address TDD from a productivity standpoint with some research data that I've seen. (More / better links welcome too!)

by compay 16y ago

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.
- torial 16y ago
  I've been following the TDD stuff as an outsider, and hands down the article that makes me consider it with the least skepticism is this one: http://blog.objectmentor.com/articles/2009/10/07/tdd-derangement-syndrome http://blog.objectmentor.com/articles/2009/10/07/tdd-derange... I'm sure there are issues w/ the various studies it cites, but it is the only one to actually address TDD from a productivity standpoint with some research data that I've seen. (More / better links welcome too!)