I’m working with a large codebase at the moment, trying to write unit tests to ensure that the changes I’m making aren’t compromising the existing code.

For some of the code, this is easy. For other pieces, not so much.

One area that I’m finding difficult is in the area of static methods. Historically, I’ve been a fan of static methods for some scenarios. But, now I’m finding them a bit of a pain.

I stumbled upon the GoogleTesting blog and a post that says it well:

Here is another way of thinking about it. Unit-testing needs seams, seams is where we prevent the execution of normal code path and is how we achieve isolation of the class under test. seams work through polymorphism, we override/implement class/interface and than wire the class under test differently in order to take control of the execution flow. With static methods there is nothing to override. Yes, static methods are easy to call, but if the static method calls another static method there is no way to override the called method dependency.

There’s no way that I’d even consider removing the static methods from the codebase I’m working on - they’re too integral to the architecture of the system, and I’m not going to introduce any inconsistencies, for that way lies madness (or, unmaintainability, at the very least).

But, I do need to find a way to introduce a seam or two to support testability.

Comments

blog comments powered by Disqus
Next Post
Coming up to speed  10 Sep 2009
Prior Post
Linq vs Loop performance  01 Sep 2009
Related Posts
Browsers and WSL  31 Mar 2024
Factory methods and functions  05 Mar 2023
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
Archives
September 2009
2009