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.
Note on the questions regarding writing tests for the legacy project - do it. Even if it involves a super old tech stack. Once the tests are good, coverage is sufficient and integration is running you can refactor with confidence or even make breaking changes it just gives you muchore opportunities than without the tests since you never know without tests WHERE (not if) regression is introduced.
And in the process the test suite and tech stack can be updated step by step. This expensive but cheaper than keeping it legacy
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.
Note on the questions regarding writing tests for the legacy project - do it. Even if it involves a super old tech stack. Once the tests are good, coverage is sufficient and integration is running you can refactor with confidence or even make breaking changes it just gives you muchore opportunities than without the tests since you never know without tests WHERE (not if) regression is introduced.
And in the process the test suite and tech stack can be updated step by step. This expensive but cheaper than keeping it legacy
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!