Things I learnt by not writing tests

<i>Firstly, writing test-first permanently changed the way I write code .... They still tend to be short, descriptive and as self-contained as I can make them, and as a result easier to understand and change</i><p>I learned exactly the same lessons from writing code in a functional style. The experience changed my style for the better, and that carries over even when I'm using a language that doesn't lend itself very well to functional programming.

I'll give my usual critique of religious TDD:<p>Most of the features I develop aren't good ideas in the end. Writing a test for a feature that you are going to dump after testing it with actual users is a waste of time.<p>Once a feature has proven its worth, I write tests to protect its value.

I completely agree about the power of test-driven development, but I think the take-away hits home the most:<p>"...shaking things up, doing things a different way for awhile..., is never a bad idea."<p>I recently spent some time forcing a friend of mine to learn some basic Scheme (which I learned in school, and have always loved), to try his hand at programming. This led to basically reading though my Scheme book again and hacking through some examples. Going back to work - developing in Java - I found myself writing much more concise code and spending enough time thinking about the problem to find a solution that felt elegant.<p>Edit: I'd add to the article's point by saying: don't stay in the same environment for too long, or you'll get stale. Switch things up from time to time, even if that means switching to an environment that is inferior in some ways - you'll get something out of it.

"<i>Secondly, I've realised that when I don't write tests I code too fast.</i>" Excellent inadvertent criticism of TDD. Thanks for the post.

One thing that discouraged me "Test-driven development is difficult to use in situations where full functional tests are required to determine success or failure. Examples of these are user interfaces, programs that work with databases, and some that depend on specific network configurations. TDD encourages developers to put the minimum amount of code into such modules and to maximise the logic that is in testable library code, using fakes and mocks to represent the outside world."<p>A good portion of interconnected web apps are API calls, and database updates/queries. For the type of programming I'm learning/doing now (web programming in ruby on rails), the tests are never sufficient to test anything. I fire up a browser and get a user eye view of what's happening while looking at the log. Maybe that's old school thinking but it's working well for us as this point.<p>Would appreciate any tips to help us be more efficient of course (victusmedia.com)

I use TDD on all my projects. I also regard myself as extremely pragmatic in my work. If I felt I would do better without designing test-first I would not be doing it (on some projects I have less-than-full coverage because it felt like the investment was not worth it). On to my point...<p>One thing that always frustrates me in these debates is all the hypothesizing people who are skeptical of TDD do about what it would mean if they were to use it. For example:<p>"For the type of programming I'm learning/doing now (web programming in ruby on rails), the tests are never sufficient to test anything."<p>RoR is specifically built to make test-driven web development easy. I'm not saying the poster is wrong not to use TDD on their project, just that statements like that should not be taken at face value. It is clear that at least for some people doing certain types of work TDD is a big help. That's an indisputable fact. Therefore, the only reasonable positions one might hold are the following:<p>1) I agree with these people. TDD is great and I use it all the time. 2) I don't want to use TDD. It just does not match the way I think about my work. I choose not to use it, but I do not claim to know why using it is a bad idea. 3) I tried TDD and mastered it. Anyone well-versed in TDD would confirm that I can do it "the right way". I found the following problems in my test-driven code: ... For those reasons I would recommend that people stay away.<p>I think any other position would be disingenuous or lazy. Also note that only opinion 3 is in any way interesting to read about. It kind of feels like unless you're making that claim there is no useful way to comment on the utility of TDD.

Why not test rails apps?? That's the bit I don't get... for starters get a hold of sahi <a href="http://sahi.co.in/w/" rel="nofollow">http://sahi.co.in/w/</a> (other web test tools also exist...). Voila simple tdd in the browser environment.<p>In defence of the article, tdd is something i do in my head but rarely to the nth degree in practice. I'm more of a fdd kind of person, but I think that there are a lot of parallels with the two approaches.

In a similar vain to what the author is talking about by writing tests you probably end up creating a better api, especially if you write the tests first.