TDD stands for Test- Driven Design, and this means that a constructor cannot really be βby designβ if you cannot test it.
Think about why it is internal. This will show you how to solve this problem. You do not have to publish a constructor to test it, but you should consider a design that makes it easy to create new instances.
Often, constructors become internal to protect invariants, but you can also achieve the same goal with a public constructor that accepts the required input as constructor parameters.
public class MyClass { private readonly string requiredString; public MyClass(string requiredString) { if (requiredString == null) { throw new ArgumentNullException("requiredString"); } this.requiredString = requiredString; } }
Note that a combination of the Guard clan and the readonly keyword protect the class invariant. This is often a good alternative to internal constructors.
Another reason for having internal constructors is when you have a Factory method that can return a polymorphic object, but think again, it would be a problem to expose the constructor if that doesn't mean compromising invariants.
The beauty of TDD is that it makes us look good at any design decision and be able to truly justify each of them. Consider the rationale for creating an internal constructor, and then the modfiy API so that the type is easily created.
Mark seemann
source share