Hacker News Reader

Small changes. If possible, pick a bit of logic and extract it into a (unit) testable function. Release it, see if anyone shouts. Repeat.

Even then, it is often hard to justify this work/find the time. It depends on how long you think you'll be working with the codebase really.

Edit: the above assumes you have something like CD/fast release cycle. If not, then it's not really viable unfortunately.

View on HN

That approach is almost guaranteed to introduce bugs into complex systems. It’s fine if you’re doing something directly useful at the same time, but just be aware of the risks.

Though that dependent on what you mean by legacy. If nobody’s touched it in 5+ years it might very well be unchained when the system is completely replaced with something else. It’s well worth adding tests if something is or will be in active development.

> BUT you know that you should. If you don’t, you’re making things worse! If you don’t write the tests, you may even break something and you won’t realize!!!

Slowly adding tests is fine if your goal is to increase the total code under test, but it's not going to give you much confidence that you didn't just break something when making updates to the system.

Reply on news.ycombinator.com