[MoreQARespect]

I've seen it done properly with unit tests on algorithmic or decision making code (parsers, calculators, complex, deterministic thinking code).

I've seen it done properly with integration tests on integration code (CRUD, messaging, websites, etc.).

However, people do insist on writing unit tests on integration code and when they do it, it all goes horribly wrong.

[twic]

I was in the middle of writing a reply to the comment you replied to, when i had to stop because my app was crashing in staging, because i had written a unit test for integration code.

[latchkey]

I built an app that ran on 30k+ servers across multiple data centers and it had an auto update mechanism because the app needed to be routinely updated with new features.

I had an integration test that ensured that the app would start up correctly and that the self-update mechanism worked. Without those tests, any failure to start would cause me to have to "talk" to 30k+ servers to get it to install a new version of the app. (ssh into each server and re-install the app).

Automating that communication across that many servers (many of which could be rebooting at any time) and ensuring that they all had a running version of the app, was difficult to say the least. How do you even track that the app is running? (You end up having to have a ping mechanism too!)

Of course, I didn't start off with those tests and had to do things the hard way more than a few times. The thing is that once I added the tests, I never once had to do things the hard way again.

So, you can certainly do things the hard way, or you can just write tests and be done with it and work on features instead.