With every project comes the challenge of hitting deadlines and being able to produce end results in the most timely manner. Even with personal projects that do not run the risk of upsetting investors, there is still an overarching goal of keeping deadlines short so that the project stays alive and doesn't fall into the dreaded "soon-to-be-finished" folder on your desktop. All that in mind, coming up with tests for production code is usually not synonymous with time efficiency. For each line of production code there will be 2-4 lines of test code. At face value of following the Test Driven Development strategy, the project has grown two to four times larger just by adding tests. Because of the daunting scale, it can be very tempting to forgo any testing and opt for the old fashioned way of developing by pulling your hair out when a bug appears later on in the project instead of writing all of those tests. Surely that is a lot easier than having to write all those tests, right?
Well, yes and no. As I am beginning to learn more about TDD, I definitely see the benefit of testing, especially after having lived the nightmare of working on projects that do not have adequate test coverage. Where a developer might lose out in time writing tests, they will definitely make up for it with the lack of time spent debugging. As the project gets bigger, so does the likelihood that something will go wrong. It also means that the haystack that needs to be filtered through to find that needle-sized bug breaking the project is also that much bigger. Writing tests and TDD prevents this from being as big of an issue, because you have a test that will point out exactly where the needle is in your haystack and how it got there.
Since tests are great and solve a lot of heartache, but there are real world deadlines that need to be met, sometimes it is good to find a healthy compromise between the two. In general, the more test coverage the more secure you are, but there are some things that are less likely to fail. For example, it is pretty safe to say that any basic math function is going to succeed as long as the function has the proper data types. On the flip side, I feel like integration tests are pretty much essential because there is so much that can go wrong in the handshaking process passing information from the server, to the back end, and then to the front end without something going wrong. Edge-case integration issues can shut a project down for weeks trying to patch weird instances where there is either missing data, duplicate data, or other weird bugs in the program's logic.
Writing tests for your code is like having a built in insurance plan for your project. It does wonders for your confidence having a safety net below as you plow through the unknown that is software engineering. While there are some cases where you don't need to be too cautious, it is always better to be safe than sorry.
Comments