Search code examples
design-patternstddsingletonstatic-methodsstatic-classes

Should I never use static methods and classes and singletons when following the Test Driven Development paradigm


I've been reading that static methods, static classes, and singletons are evil when you try to implement unit testing in your project. When following the TDD paradigm, should I just forget that they ever existed and never use them again or is it ok to use them sometimes?


Solution

  • Never say never--static classes and methods have their place in your toolbox.

    That said, if the class you are trying to isolate and test (subject under test or SUT) depends on a static class or method, you will be unable to write a test that isolates the SUT from that static dependency--when your test code runs it will still use the static call. Sometimes this is fine, but sometimes you want to create an isolated test that tests ONLY the logic of your SUT with no dependencies (usually via mocking or similar techniques).

    In general I personally use static classes and methods relatively sparingly.

    Due to the nature of how Singletons are implemented, they present a similar problem for isolating a SUT for unit testing. In addition, the GOF singleton concept is considered to be a bad practice by a certain percentage of software developers. I happen to agree with this sentiment, but there is hardly consensus on this subject. A quick search on google will probably give you a pretty good idea of the pros and cons of the GOF Singleton pattern.