TDD: tastes better without the T?

We should make up an entirely new buzz-phrase for this. How about Incremental Development?

Yes, yes I am. :) The reason being, that first, it's annoying to have to set up the boilerplate for the file. Second, it's annoying to have to convert what I just exercised in the REPL into a test. (Setup, tear down, asserts.)

The reason TDD works and is fun is that you are using tests to learn and explore. It just so happens the artifact of that learning ends up living forever as a test. In a REPL, I'm doing that same learning and exploration already. The act of writing a test becomes as exciting as filing a TPS report.

Here's an example. I've just implemented a new function, and REPL'ed it to solidity. There were about 4-5 ad-hoc calls I made to the function to prove that it worked. I just finally got to the point where I can call it using my 4-5 different arguments, and it always outputs the right thing. Using readline, my arrow keys, and my enter key, I'm repeating the same series of steps over and over until the function works. We all do this. Win.

Now, I'm at a crossroads. Do I just start working on the next piece of the project? I know this piece works, I'm happy with it.

But wait! What if something changes. I need to write a test don't I. Sadness consumes me, since testing is slowing me down. I've already exercised the code, I already know it works, and I've already written the tests, albeit sloppily, in the REPL. Why do I have to switch gears now and start writing a file, running a test runner, and so on?

The truth is: I won't. I'll move onto the next thing, not breaking my flow and not doing something boring, something I already know the outcome of, instead of doing something fun: the next feature.

Maybe those who do switch off and go through the motions to write a test, repeating themselves, are more noble and careful in their programming. But I humbly suspect most of us are more lazy than noble :)

Not only that but they tend to be fragile and break when something in Rails or the other sub-frameworks they depend on changes. Somewhat ironic actually...

My use of tests is situational.

If I'm writing security-sensitive string parsing code that isn't going to change much, I'm going to write a thorough set of unit tests.

When I wrote database abstraction layer that ran on MySQL, PostgreSQL, Microsoft SQL Server and Oracle, I found that a good set of tests made the process of porting the system to a new database almost trivial.

Back when I was getting my PhD, I rewrote a simple-but-slow calculation to use a fast-but-complicated-as-hell algorithm, and I don't think it would have been possible (to get the right answer) if I hadn't used the simple code to create unit tests for the complicated code.

On the other hand, there are a lot of cases where I've written unit tests and they've become a liability over time; for instance, requirements would change, so I'd have to go back and maintain this collection of tests that, frankly, I didn't care about anymore.

I can completely understand there being disagreement about how to test code, how much testing is enough, when to write test (test driven vs write tests later), etc.

But what boggles my mind is we've got people in this very thread who, if I'm interpreting their comments correctly, are arguing against doing any testing at all! WTF? How, in any non-trivial codebase, are you going to prevent regression?

Does anyone here have any experience in another engineering discipline (civil, mechanical, electrical engineering, etc). Isn't some sort of testing an accepted part of the process?

Maybe I'm wrong, but this seems like a huge sign of the immaturity of the discipline of software development.