Step up Your Software Career with Test Driven Development
For me, test driven development - writing the smallest failing test before writing the code to make the test pass. How to write the smallest failing test? I covered it in this post.)
To step up one’s career as a software developer, I expect those team members to have test driven development as part of their practice.
As everyone on the team will be contributing to a codebase consisting of:
- your code
- their code
- and code of all past team members
Think about that - the code in production is not only yours and the current team members, but past team members too.
I want the highest quality possible code in production. Not only for me, but for all team members that are on-call for production issues. Solving production issues is important to the operation of the business, not to the individual glory.
Of the following code styles, which is the highest quality? Which would lead to the easiest resolution of production issues with the fewest team members?
- code without tests
- code with useless tests
- code with happy path test (bare minimum tests)
- code with tests that validate all known situations at the time of development
I want all team members to have, ideally, zero production issues to solve. Hence, you are doing me, yourself, your team members, and future team members favor by doing test driven development now.
As you advance in your career, you will eventually be on-call for production issues. Which of the above code base would you want to have when you have to solve a production fire alone Saturday night?
My recommendation is to write tests first, in a test driven development manner so you will have an easier time when a production fire comes at you on a Saturday night.
Not only will you appreciate it, all your team mates will appreciate your effort because you solved the fire without interrupting them.
This will also help you level up in your career as a software developer.