2

On an entry level for a codebase you are not familiar with, how do you introduce testing, an at what levels ?

When introduced to codebases with no tests at all and at the same time being tangled together, it's difficult to measure where it's best to put in the energy.

I often pick a smaller corner to start from but in messy codebases that corner often grows bigger the more I dig into that initial corner. So all of a sudden I have my hands full and from a small corner I find myself refactoring a lot more than I set out to. Which is not a bad idea but I was wondering if I could use another strategy.

I also have a hard time writing tests for something I know I will change over short time, but is this a valid argument ? Is there a sweet spot for when to introducing tests into a messy codebase ?

Thanks a lot!

2

1 Answer 1

Reset to default
10

Yeah this is not easy to solve. A common property of messy big-ball-of-mud architecture is exactly that lots of modules and effects are interconnected in such a way it is difficult to isolate units for testing. Refactoring to break dependencies and isolate side effects is in itself risky operations if you don't have unittests, so this is a chicken-vs-egg problem.

In that case, focus first on integration tests testing the system as a whole. Only mock external services. You may need to create a full test-database with the same scheme as production database and with sample data. (Remember to script this, so the database can be recreated after each test.) Then write tests simulating actual use cases of the system.

This is going to be some work, and the integration tests are probably going to be slow to run.

When you have covered a significant range of use cases, then you can start refactoring by isolating external services, database layer and so on. This refactoring will make it possible to test gradually smaller units of code. You want to reach the level where you can perform new development in a TDD-style, but it might be long journey to get there.

2
  • 1
    Great advice with integration tests first.
    – frostings
    Commented Sep 20, 2017 at 7:16
  • Exactly. Although you can do either way, this is the safer one. Most old codebases I've seen wasn't written with unit testing in mind therefore needed a lot of mocking (sometimes it can be even as complex as the code itself). When you have integration tests you can refactor the code and cover it by tests at the same time while having a proof it didn't break any use case.
    – eMko
    Commented Sep 20, 2017 at 12:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.