First, always have a way to test your code, and always make sure you are testing your code before deploying it. This, to me, is the essence of test-driven development.
Whether you should do unit tests or not really depends on how easy it is to test the feature you are testing.
Some blocks of code are deployed directly on the main the path and are therefore easy to test. You simply fire up the app and go to that screen.
Other blocks of code are deployed outside of the main path and require a complex set of conditions to trigger them (date-based logic, complicated enterprise workflows, uncommon error states).
In my experience the latter is where you get the best bang for your buck with unit tests.
Maybe you've got some receipt validation logic that only gets run after a user logs in, picks out an item, goes to the checkout, pays for the item, etc. If the receipt validation logic is run at the end of that long chain of events, it's going to be difficult and time-consuming to manually test all of its possible success and error states.
So why not break the receipt validation module away from the rest of the flow and send some sample data through it so you don't need to keep wasting time going through all of those steps just to test a single part of it?
Since you have determined that it is too time consuming to test the receipt validation module at the point of integration, you take the wiser path and test it as a completely separate component.
Unit tests are like my Cuisinart Food Processor. I don't use my Cuisinart for most kitchen tasks, but some tasks, like making almond butter, are utterly impractical and ridiculously time consuming without it.
When unit tests are the right tool for the job, nothing can replace them. But I don't throw everything into my food processor, and neither should you.
Thanks for this solid practical advice :D
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.