Increasing Code Coverage
Bottom-up means you are adding low-level unit tests. And as Philp says, it’s very hard to write tests for existing code. Top-down means you start at the interface level- You write tests for the API or any other interface, and add more integration-level tests to cover more portions of the code.
So what can you do to increase code coverage? TDD is great, both in the unit and acceptance level. We are trying to work with TDD whenever we can. But what if you can’t use it? Is a TDD rewrite, as one of Philip’s options, a must?
Isolator to the rescue! This is where Isolator shines – you can isolate whatever dependencies you need in order to test the logic you want. Add more tests as you go and you can increase coverage by many folds.
There is a caveat I want to mention regarding doing TDD in a bottom-up fashion. It’s a pitfall, we (well, me) sometimes (ok, many times) fall into.
It’s very tempting to start at the bottom. It’s more focused, you know what you want and coding is smooth. But you also need acceptance tests (which are top-down). For example, in our new API, we’re inserting code into the existing framework, because obviously, we are building on it. But if you start at the bottom, you may end up with a beautiful component, only to need some rewrite in order to fit into the existing code base, and pass the acceptance tests.
So back yourself up. And, as a bonus, you’ll end up with more coverage.