Telerik® JustMock™ by Progress

The automocking container makes Telerik JustMock even more appealing, due to out-of-box support for IoC. Developers do not need to find the appropriate auto mocking container and make it work.

Important

The Telerik.JustMock.Container namespace and the Telerik.JustMock.Container assembly are now obsolete. Please, use the Telerik.JustMock.AutoMock namespace found in the Telerik.JustMock.dll.

Overview

Automocking allows the developer to create an instance of a class (the system under test) without having to explicitly create each individual dependency as a unique mock. The mocked dependencies are still available to the developer if methods or properties need to be arranged as part of the test.

For simple classes with few dependencies, automocking provides only marginal benefit. The real benefit comes with complex classes with multiple dependencies, or classes that change over time. Tests written for the methods in these classes typically do not need all of the dependencies explicitly mocked as part of the act or assertions, but they are required for class instantiation in arrange. Automocking allows the developer to focus on the dependencies they care about for the specific test and essentially ignore the rest.

According to Single Responsibility, if a class has too many dependencies it should be refactored to be more concise and focused. Whether the class is left with the multiple dependencies, or gets refactored into smaller classes, automocking reduces the friction of changing unit tests. The tests that requires specific mocks will still have those mocks accessible through the automocking container, and will dynamically adjust the instantiation of the system under test (SUT) based on the constructors requirements.

The Telerik JustMocks MockingContainer uses the Ninject dependency injector to do the heavy lifting. However, as the MockingContainer holds all of the Ninjects functionalities it also expands them in a way to fit well inside Telerik JustMock. The final result is a mocking tool that uses the Ninject dependency injector for resolving dependences for a given class. As said, users will remain completely unaware of the underlying IOC container and there will be no reference of Ninject in their code whatsoever.

As MockingContainer<T> derives from Ninject.StandardKernel, you can configure it just as you would configure the Ninject dependency injector. Visit the Ninject official page or the Ninject wiki in GitHub for further references.

Automocking Interfaces

Assume that we have the following code, to be tested:

As you can see, our ClassUnderTest has two external dependencies:

To test the class under test against certain scenarios you will have to mock the dependencies. One way to do this is to mock them one by one and arrange their behavior as shown below:

  1. We create a mock object of FirstDependency and SecondDependency.
  2. We create a new instance of our ClassUnderTest with the mocked dependencies.
  3. We arrange the behavior of the dependencies and the CUT.
  4. We act.
  5. We assert our expectations.

This will work for certain scenarios, but not for all of them. For example there will be scenarios where you will have more dependencies and all of them needing to be mocked. In these cases you will find the JustMock`s mocking container very handy. Next is how the previous example will look like using the Automocking feature:

  1. We create a MockingContainer from our ClassUnderTest.
  2. We arrange the behavior of the dependencies and the CUT.
  3. We act.
  4. We assert our expectations.
C# Note

using Telerik.JustMock;

using Telerik.JustMock.AutoMock;

Visual Basic Note

imports Telerik.JustMock

imports Telerik.JustMock.AutoMock

In this way, your test method stays more consistent and adding another dependency, won't break it's logic.

Another way to assert the arrangements is shown in the next example:

This style of assertion let's you focus on the arrange, as a container of your tests logic.

Elevated Automocking

Note

This feature is available only in the commercial version of Telerik JustMock.

Refer to this topic to learn more about the differences between both the commercial and free versions of Telerik JustMock.

Important

To use Elevated Automocking you first need to go to elevated mode by enabling Telerik JustMock from the menu. How to Enable/Disable Telerik JustMock?

The functionality of the JustMocks profiler enabled automocking feature is rather the same as the conceptual design of the automocking, as a whole.

Following this article, you will see examples that should explain how Elevated Automocking is used inside JustMock test methods:

  1. The first example shows how easily inheritance could be handled using this feature.

    Assume, we have the class below with its dependency:

    With JustMocks Elevated Automocking we are able to directly write the next test:

    C# Note

    using Telerik.JustMock;

    using Telerik.JustMock.AutoMock;

    Visual Basic Note

    imports Telerik.JustMock

    imports Telerik.JustMock.AutoMock

    This saves us the time of creating independent mock for our dependency, and further, the inheritance is preserved.

  2. The second example shows how multiple dependencies of the same type could be managed with the Telerik JustMocks MockingContainer.

    Note the following classes:

    Again, we are able to directly apply the next test method:

    C# Note

    using Telerik.JustMock;

    using Telerik.JustMock.AutoMock;

    Visual Basic Note

    imports Telerik.JustMock

    imports Telerik.JustMock.AutoMock

    Here, you are able to arrange the behavior of the different Account dependencies, from the mocking container.

    Note that, you are free to add more external arguments to the AccountService class, and this will not break the consistency of your previously created test methods.

See Also