At Launch Academy, we are exposed to and taught best practices for software development. One of those best practices is that of test-driven development, or TDD. As the name implies, it is a method of programming where your tests guide your decisions.
The idea is to reduce the feedback loop on your code. It’s an iterative process, consisting of writing a test, writing code, making that test pass, and then refactoring the code. Based on any errors you receive when running the code, you’ll be able to determine what the next required step is. It helps you figure out what you want to do, and then implementing the minimum amount of code needed to make that happen.
I find this style of programming very satisfying, as you will see visual indicators showing progress you have made. It’s almost like seeing checkpoints or objectives in a video game, which you must pass in order to advance to the next level.
Additionally, I find that it helps me write cleaner, leaner code. When writing a test, it forces you to think of how that part of your program will function. This gives you a clear direction of what code you will need to write next.
Prior to committing to learning software development, I worked in software quality assurance (QA) writing and executing tests. I helped to maintain and create new test cases for various features of the company’s web application. This experience proved to be helpful when writing tests, as I was used to coming up with various edge cases and trying to “break” other people’s code.
I loved catching bugs that slipped by while in QA, and now have the challenge of identifying potential potential bugs as a program is being written. Though it requires a slightly different way of writing code, which results in more upfront time, the potential for saving time overall makes it very worth it. I’ve seen many times where bugs have been caught before shipping, but then the source of the bug had to be determined, which can sometimes be the most challenging part of the process.
Writing code procedurally, focusing on one test at a time, definitely seems like the most efficient way to produce “bullet-proof” code. I’m on board with the TDD way.