The sort answer would be... "yes, for a while".
The a-bit-longer answer would be...
The goal of having a test suite is to validate that certain use cases function as expected. Thus, no matter how the internals of your systems look, if you can validate that the uses cases work as expected... you should be good!
This might sound counterintuitive and many of you might be thinking "fix your system and write tests for your new code". I understand that point... however the thing is that, in a running business context it's very hard to just re-write a project or deprecate an old version of a project and move all customers to new one. Even re-factoring can be "dangerous" unless you have something to test the changes against to verify the changes.
Some of you might be thinking "you might be able to verify use cases, but with bad/legacy code you won't have fun releasing new features". That is also a valid point!! Just because you managed to make a high quality test suite in order to "cover your **s" from buggies, that doesn't mean that you will be able to release features faster. The test suite though, should be able verify that your hustle through bad/legacy code didn't break anything.
From the above points we see that, if you haven't taken care of your codebase, just testing/verifying your use cases wont get you very far on its own . Having such a test suite though, can be a great tool in the process of improving/re-factoring your system. Having documented and written test suites can help you verify that changes in code work in the same way. Additionally, in the case of re-write, it can help verify that the same use cases are working in the same expected way in old/new code.
Conclusion
Before you just straight into re-factoring or re-writing a codebase, I think it would be wise to spend some time documenting and testing your current use cases. In that way, you will be able to verify that old/new code work in the same way without any disruptions for your users when you release that code (hopefully🤞).
Top comments (0)