A TestBase class for auto mock and constructor testing and other test helpers using Moq.
- Reach every function from test code:
- Use
internalinstead ofprivate - Add an
AssemblyInfo.csfile to each project that exposes internals to the test assembly - What about encapsulation? You should not be calling your class directly but exposing an interface that matches your public functions. Whether your functions are
privateorinternalshouldn't be noticeable anywhere.
- Use
- Mark functions with
virtualto allow Moq to override them- In addition to a mocked unit under test, you will also get a
MockObjectwhich allows you to mock and verify other functions on your unit under test. This only works if Moq can override your function. - Additional requirement - can't use
sealedon the class, as Moq needs to inherit from it.
- In addition to a mocked unit under test, you will also get a
- Write small functions!
- Single Responsibility Principle (SRP) - have your functions do one thing to help isolate code to test.
- Beware of the word "and" - if your function does this and this and that, it likely does too much.
- Do not use
staticclasses or functions- You can't mock it out and thus have to also test what the static function does from each and every caller.
- If you really need a static class, make it a singleton with an
Instanceproperty as a get-out-of-jail free card.
See the SampleApp in the solution or /sample folder.
App.cs is how code would be expected to be written.
TestableApp.cs is how the code looks like adhering to these code guidelines for testability.
The associated AppTests and (TestableAppTests)(/sample/SampleApp.Tests/TestableAppTests.cs) demonstrate the difference in testability.