In this post I’m going to talk about how we can write more maintainable unit tests.
A unit test verifies if the system under test is working the way it should, but how can we trust the test?
Functional programming uses the option type widely, in languages such as Haskell, F#, Scala and a lot more. In this language it’s a convention to return a value when the function fails. The following example is a function written in F#, to show how the option type works:
In programming null is an awkward thing to deal with, when you return a variable with null value, you have to remember to make null checks all around your code.
You can download this sample from this git repository.
When you start to write unit tests, inevitably you’ll encounter a hard time when a functionality depends on time. Depend on DateTime.Now doesn’t work well for unit testing, your tests will pass on certain time of day and fail in others.
SUT factory may be a fancy name to what is basically a utility method, used to create an instance of the system under test. The main point of a SUT Factory is to reduce code duplication and improve maintainability of your unit tests suite.
In my last post I talked about stubs and how to you can use them to isolate external dependencies in your unit tests. In this post I want to talk about another type of test double, Mock Objects.
The definition of stubs can cause confusion sometimes. There are many definitions that you can find in a lot of places, stubs and mock definitions can be pretty similar sometimes, and have a good understanding of both can make the difference when writing highly maintainable unit tests.
Naming classes, methods, variables are hard, perhaps one of the most difficult things in programming.