4 ms·

Just a note on legacy tests: Step 0.5: understand the tests. They need to be examined to see if they've rotted or not. Tests passing/failing doesn't really mean

Just a note on legacy tests: Step 0.5: understand the tests. They need to be examined to see if they've rotted or not. Tests passing/failing doesn't really mean code under test works or not. The tests might have been abandoned under previous management and don't accurately reflect how the code is _supposed_ to be working.

dataflow 3y ago
I'd put that under 2.5 or 3.5, if not later. You only really need to do it before you start modifying code, and it's a massive effort to understand a new codebase. Better pick the lower-hanging fruit (like corruption bugs) so you can at least stay sane when you run the tests and try to understand them.
fransje26 3y ago
Look at mister fancy here, having tests in his legacy code base.
mst 3y ago
The same applies to comments. I have absolutely inherited codebases where one of the early steps was to make a commit excising every single comment in the code, because so many of them were old, lies, or old lies, that it wasn't worth the risk of a junior developer accidentally thinking they could be relied upon. (and of course they remained available in history to be potentially buffed up and resurrected, but still, argh)
- dataflow 3y ago
  That's brilliant, but also... sounds like hell? Wouldn't that easily add several months to the timeline?
roland35 3y ago
I find it helpful to try and intentionally break the code under test. Sometimes the test still passes, and that is a good sign that something is very wrong!
Zobat 3y ago
My project has decent code, source control with history from the beginning (ten years in a few months) and unit tests that were abandoned for years. I've spent at least a couple of weeks, over a year or so, just to remove tests that didn't test current functionality and get the others to work/be green. They ain't fast and only semi stable but they regularly find bugs we've introduced.

dataflow 3y ago

I'd put that under 2.5 or 3.5, if not later. You only really need to do it before you start modifying code, and it's a massive effort to understand a new codebase. Better pick the lower-hanging fruit (like corruption bugs) so you can at least stay sane when you run the tests and try to understand them.

fransje26 3y ago

Look at mister fancy here, having tests in his legacy code base.

mst 3y ago

The same applies to comments. I have absolutely inherited codebases where one of the early steps was to make a commit excising every single comment in the code, because so many of them were old, lies, or old lies, that it wasn't worth the risk of a junior developer accidentally thinking they could be relied upon. (and of course they remained available in history to be potentially buffed up and resurrected, but still, argh)

dataflow 3y ago
That's brilliant, but also... sounds like hell? Wouldn't that easily add several months to the timeline?

roland35 3y ago

I find it helpful to try and intentionally break the code under test. Sometimes the test still passes, and that is a good sign that something is very wrong!

Zobat 3y ago

My project has decent code, source control with history from the beginning (ten years in a few months) and unit tests that were abandoned for years. I've spent at least a couple of weeks, over a year or so, just to remove tests that didn't test current functionality and get the others to work/be green. They ain't fast and only semi stable but they regularly find bugs we've introduced.