I used to be a test engineer and was weaned on the dogma of people like Martin Fowler and Misko Hevery. Tests are very useful and can become indispensable on la

I used to be a test engineer and was weaned on the dogma of people like Martin Fowler and Misko Hevery. Tests are very useful and can become indispensable on large, complex projects. As I was evangelising tests to the devs on my team for a year I had all these kinds of clever answers for people who didn't want to write them. Now that I'm a 'proper' developer, working at a startup building software from the ground up I hardly write any tests. My main beef is this thing about refactoring vs rewriting, I like to have the freedom to change class responsibilities and relationships in my code as the project develops and the responsibilities and design solidify. Problems come up and get worked around and you can't always foresee these things. I find that sitting down and writing a very well intentioned set of classes, in a pretty hierarchy, with defined interactions is not a good way to build new software. But unless you write your software like this you will inevitably spend lots of time rewriting tests as you rewrite your application code. Tests are good when you have an architecture and API sent from on high, for which only the implementation needs to be worked out. Tests are not worth their weight when your architecture is code-driven and you design as you go. The best way to design software - that's another, very lengthy discussion.