When is it OK to not write a test?

As much as I love TDD and automated testing, sometimes it just doesn't fit in. I can assure you though, writing atleast one test that covers the majority of a requirement, is very worth it.

To answer the question "When is it OK not to write a test?", I'm going to have to say "never". If you break down the metrics as follows:

1. Write code
2. Stop application that's running in test environment
3. Clear/delete any logs
4. Start application in test environment
5. Click buttons, enter values, waste more time
6. Check all the values after doing Step 5

The above is just not feasible to sustain any type of momentum. Most projects are written like this, we must stop wasting so much damn time. The second I find myself doing something repeatedly I think, "How can I make this a test of some sort?". Whether it be integration or unit or just something automated, the redundancy must be removed.

Instead of the above example, do the following for each elementary business process:
1. Write test (NUnit framework)
2. Run test
3. Test failed (because there's no code, obviously, so now we have a test that we know is failing)
3. Write Code (so we can get the test to pass that we coded)
4. Run tests
5. ... rinse and repeat