Programming isn't just writing a program, especially if you're coding professionally. You need to think about writing tests if you're coding as a member of an organization or team. This is still true even if your focus is developing new features. Today, I'm going to try to convince you that tests are worth your time.
When you're part of a larger organization with multiple teams working together, it's better to find problems earlier. Let's look at the impact of finding a bug in different phases of development.
If you can find a bug in the requirements phase then you might be looking at a two-second decision that saves you days of coding down the wrong path.
You may face a small inconvenience of a couple minutes if you find the bug while implementing the code.
However, if you release your code to the rest of the team, then it might waste hours of QA or UAT time to find the bug. Even then, you still have to fix the bug. (Remember, the fix is the same no matter who finds it; you'll be making the same commit to the repository.) After that, your team has to re-test your fix. When you wait longer to find a bug, you start wasting other people's time, not just your own.
In the worst case, if you have a problem in your code and you release it to production, you may actually be spending the rest of your career dealing with it. Really! Sure, the result may simply be a couple panicked hours of fixing and redeploying. Worst case, you could be creating a foundational problem that your team members will build on for years. You might be setting up to maintain this house of cards for the rest of your career, adding chewing gum, paper clips, and rubber bands to the code that you just deployed today.
If you have tests for your code, like unit tests, then you can catch problems earlier. Earlier is faster; faster is better. If you have to make a fix, you should address it as quickly as possible. Write unit tests for your code so you can catch problems fast.
Tests will give you and your team confidence to make changes to existing code. Frequently, you will be unavailable when the time comes to make changes to the code you are writing today. Having tests allows your teammates to confidently change your code, especially junior developers. (If you've ever had to modify existing code as a junior developer, that can be pretty intimidating without tests!)
Be a good teammate and write unit tests so any member of your team can make a change without fear of causing a regression. Remember, that teammate could be a forgetful future you!
My biggest programming pet peeve: scope creep. The scope of projects tends to get bigger over time; more is added instead of delivering the product to the customer and scheduling any additional enhancements into future sprints. The main idea in agile methodology is to get the customer the most important features as quickly as possible. This can be accomplished using TDD (test-driven development).
In TDD, tests are written before development begins. When you write the test before the code, you only implement what is necessary to get that test to pass. This forces you to stay focused on the exact scope outlined in planning. Tests that are written beforehand enforce the predetermined scope of the project to avoid letting it get out of control.
To every developer who doesn't write tests before they begin development on a new feature, I ask: how do you know when you're done? A developer using TDD test-driven development will be able to answer: I am done when all of the tests pass. Any developer without tests is just guessing that they are done.
The inverse is also true: tests allow your team to prove themselves to YOU! You may trust your more seasoned teammates, but you may want to keep a closer eye on the team's new hires and temporary contractors. Tests allow for accountability without requiring you to check every line of their code.
Look, I know agile says documentation isn't the most important thing in the world, or at least it shouldn't be your main focus, but all features need some form of documentation. When you're onboarding someone new onto the team, you need to be able to explain to them what everything does. Sometimes you forget and need a reminder. If you don't have any documentation or any sort of manual, you just have to rely on everyone remembering everything correctly.
Having some form of documentation is good, but if you're going to have documentation, why not have working documentation? Test documentation has a dual purpose of providing confidence in the code and explaining what the code does.
Tests are better than static documentation written years ago; they are prove-ably true. If you ever wonder if the tests still accurately document the code, then all you need to do is the tests! If the test pass then you know they are current and correct.
Originally posted on Sam Does Code. Hive blog powered by ENGRAVE.
