We’ve all heard plenty about TDD throughout the Flatiron curriculum. Regardless of whether you write your tests before or after, you have to write tests. Why?
In Agile, a product is built incrementally by first identifying and delivering the smallest version that provides value to the user and/or customer. The early release of a working iteration establishes a feedback loop through which the business observes and engages with users and other stakeholders to validate assumptions and refine its understanding of the problem. As more is learned about how the product is being used, future features are reprioritized to maximize the value delivered. In short, the business consciously allows the solution to evolve as new information is obtained while simultaneously managing the risk that large amounts of resources are spent on something that no one wants. If you know that course correction is going to take place; you need a low effort way to determine that previously delivered features are still working as expected so that you can keep moving forward.
In this environment of continuous improvement, we’ll be adding to existing code instead of going from zero to deploy. No one wants their code-base to morph into Frankenstein, so coming at the problem with a surgical mindset is better for all parties involved. By writing tests, you are stating how you have interpreted the provided business requirements. Doing so allows for productive dialogue to take place with the Product Owner, while also adding a structure that encourages developers to build what is being asked. After all, we have all been guilty of endlessly tweaking some feature that was not that important.
Writing a good test suite goes beyond just understanding the syntax. If you spend a few minutes in an algorithm class, you’ll quickly see that testing is not a silver bullet and there are a million ways to break something. However, it is a lot better than crossing your fingers and hoping for the best.