A lot of us in software development would have heard of Test Driven Development. Some swear by it - some hate it and say it is fully unnecessary.
In my opinion people often attribute TDD to the following:
Write unit test -> Red -> Write code to make it pass -> Green -> Refactor
Now although this is one of the approaches that is very common I think the focus is too often given to the lowest level of testing: “unit”.
The practice is called Test Driven Development and not Unit Test Driven Development and a more accurate and common example of flow is:
Test case -> Red -> Write code -> Green -> Refactor
Unit tests are a wonderful technique in our toolbox to help us navigate the problem and keep us laser-focused, but it’s not an antidote to all coding problems. Sometimes in smaller pieces of software it is a lot more valuable and straight forward to write an Integration test first or even an end-to-end test.
Example: In AWS Lambda it is easier to have an end-to-end test that will not only test the result of the function but can catch any permission issues, this is a more likely scenario of something going wrong in AWS world :)
Of course you could argue that what I am describing is Acceptance Test Driven Development (ATDD) - and you would be right. But my main point I am trying to put across: Unit tests are useful when you break down bigger pieces of problem to help find a solution, but at some point the higher level tests are more useful - especially on smaller codebases. For example a small service.
To do Test Driven Development you don’t have to concentrate on “unit” as long as you understand the trade-offs that come with it, for example, less granular feedback of test cases and risk of over-engineering a solution.
One thing for sure: quality and tests are important. Make sure that whatever you do it helps you deploy your code with confidence.