Straw men
When test-driven development (TDD) or other test-first methods are first introduced, many people object with different variations of the same argument "if you can't test everything, it's flawed". People seem to get mentally stuck when they can't automate all test cases. Sometimes, the point gets really stretched, like, "What if the user enters a negative salary lower than int.MinValue? We don't have a test for that, do we?" or "What if the database or web server goes down? How do we do TDD for that?"
Darren Cauthon made this observation on Twitter a few months ago:
All these arguments are straw men, where an exaggeration or misrepresentation of the point is used to discount the entire thing.
Getting started
TDD won't make all your problems go away or all your dreams come true. It's something that takes a lot of practice to get better at it. I consider myself pretty mediocre at it. You will be slower at coding when you start out, but you will get faster, and I believe it is worth the investment in terms of the cleaner design it yields. The tests are nice, too. :>
The trick for me to getting started with TDD was to start small. This has also been the only way I've been able to do TDD successfully - in very small steps. Create one test for the happy path for the feature you are trying to implement. This usually has to be broken down into sub steps. Write the least amount of code you can write to get the test to pass. Once the test is passing, refactor the code to clean it up and add some polish. Then run your test again to make sure it still passes.
Unhappy paths
Occasionally test the unhappy paths, based on how likely they are and how important they are to the business. If your product owner isn't worried about int.MinValue, you shouldn't be. Move on to the next feature you're building.
You probably won't automate all your test cases, but that's OK. Your code will be decoupled, easier to refactor, and easier to read. Plus you will have automated tests for whatever percentage of tests cases you came up with.
There are far too many benefits to dismiss test-first approaches based on what it can't do well. So let's stop with the straw man arguments against test-first and start reaping the benefits.
