In general I agree with you. And you're right that the main benefit of tests is that they allow you to refactor with confidence. I've written about this extensively in these articles:
It's important to remember though that the situation can be more nuanced at times. What you've described is a legacy project, likely large, making changes frequently, and making changes with an uncertain impact. In this scenario, your suggestion to invest in writing tests makes perfect sense, especially if this is a codebase you will be working with frequently over time and that you plan to refactor and update.
Now consider a very different scenario: Let's imagine you need to make a small change in a repo that's part of a much larger app, where the last commit in the repo was five years ago, it's unlikely you'll need to make another change in this repo for several more years, and the change is narrow in scope and easy to manually verify the impact. Is it worth investing in test infrastructure for this specific repo in this case, especially if it will take orders of magnitude more time than the actual task? Probably not.
The nuance here is that the first scenario has a high amount of churn, expected changes over time, and complexity; the second scenario does not. These are important factors to consider in your decision.
This is a great point. I like the easy to manually verify part so such a tiny part of code change in the vast amount of legacy code base.
In such case, what I will do is to make sure the how-to-manually-test-my-new-tiny-change is documented with code base, so QA and whoever touching this part knows what's matter/new and how the results could be verified as expected.
Absolutely. I'm a big fan of using merge request templates to provide additional context for other developers during code reviews, and one item I always include is a test plan for how to manually verify the change. These kinds of checklists are super useful!
Graduated in Digital Media M.Sc. now developing the next generation of educational software. Since a while I develop full stack in Javascript using Meteor. Love fitness and Muay Thai after work.
In general I agree with you. And you're right that the main benefit of tests is that they allow you to refactor with confidence. I've written about this extensively in these articles:
It's important to remember though that the situation can be more nuanced at times. What you've described is a legacy project, likely large, making changes frequently, and making changes with an uncertain impact. In this scenario, your suggestion to invest in writing tests makes perfect sense, especially if this is a codebase you will be working with frequently over time and that you plan to refactor and update.
Now consider a very different scenario: Let's imagine you need to make a small change in a repo that's part of a much larger app, where the last commit in the repo was five years ago, it's unlikely you'll need to make another change in this repo for several more years, and the change is narrow in scope and easy to manually verify the impact. Is it worth investing in test infrastructure for this specific repo in this case, especially if it will take orders of magnitude more time than the actual task? Probably not.
The nuance here is that the first scenario has a high amount of churn, expected changes over time, and complexity; the second scenario does not. These are important factors to consider in your decision.
This is a great point. I like the easy to manually verify part so such a tiny part of code change in the vast amount of legacy code base.
In such case, what I will do is to make sure the how-to-manually-test-my-new-tiny-change is documented with code base, so QA and whoever touching this part knows what's matter/new and how the results could be verified as expected.
Absolutely. I'm a big fan of using merge request templates to provide additional context for other developers during code reviews, and one item I always include is a test plan for how to manually verify the change. These kinds of checklists are super useful!
More on that here: dev.to/thawkin3/managing-complexit...
Yes, totally agree with that!