TB_Release_Is_Here_870x220 (002)

Today we are announcing the R3 2019 release of JustMock which includes support for .Net Core 3.0, mocking of non-public generics, future mocking of non-public classes and support for VS 2019 version 16.2+.

Let me guide you through the new features and improvements that are coming with R3 2019.

.Net Core 3.0 Support

.Net Core 3.0 is almost here and as a follow up to .Net Core 2.+ support we've already implemented preliminary support for 3.0. Why preliminary? Because the announced official release date for .Net Core 3.0 is September 23rd. We do not expect any significant changes in the official version compared to the latest available preview version.

net core 3.0 image

Mocking of Non-Public Generics

Generics are widely used in the .Net world and they are some of the main language features used for complex architecture scenarios. JustMock has had support for Generics for many years now and we made it even better by introducing support for mocking of non-public Generics.
Consider the following generic method:

private void DoPrivateGeneric<T>(T arg)
    throw new NotImplementedException();

Here is how a mock for that method could look like:

public void ShouldInvokeNonPublicGenericMember()
    Foo foo = new Foo();
    bool called = false;
    // Arrange
        .Arrange(foo, "DoPrivateGeneric", new Type[] { typeof(int) }, 10)
        .DoInstead(() => called = true);
    // Act
    // Assert

The difference with mocking a normal non-public method is that an additional parameter for the generic type argument is required. This parameter is in the form of an array of types to support multiple generic type arguments on a single method.

Future Mocking of Non-Public Class

Another new feature is the future mocking of a non-public class. Until now it was very challenging to mock the constructor of an internal or private class or even the private constructor of a public class. With this new feature this will be possible.
Consider the scenario where your test depends on an internal class from a third-party library where in the constructor some private variables are set, and the values of those variables are affecting your test case. It is just annoying to search for a workaround, isn’t it?
The following example creates a future mock of the internal class WebSocketHttpRequestCreator with true as an argument for the constructor.

public void ShouldMockInternaldotNETClassWithArgs()
    // Arrange
    string typeName = "System.Net.WebSocketHttpRequestCreator";
    var httpRequestCreator = Mock.Create(typeName, (config) => config
        .CallConstructor(new object[] {true}));
    Mock.NonPublic.Arrange(httpRequestCreator, "Create", ArgExpr.IsAny<Uri>())
    // Act
    System.Net.IWebRequestCreate iWebRequestCreate = (System.Net.IWebRequestCreate)httpRequestCreator;
    var result = iWebRequestCreate.Create(new Uri("https://www.telerik.com"));
    // Assert
    Assert.AreEqual(new Uri("https://www.telerik.com"), result.RequestUri);

Rethrow Original Exception in PrivateAccessor

We have received multiple requests for assistance about a TargetInvocationException thrown by the PrivateAccessor.CallMethod. The requests were mainly related to questions why the original exception is wrapped in a TargetInvocationException and how this should be handled as the expected exception was different.
The reason for this behavior is that the PrivateAccessor is using internally the reflection API to invoke the required method and this is how the reflection API will wrap the original exception.
To simplify such scenarios, we’ve introduced the RethrowOriginalOnCallMethod property in the PrivateAccessor class to control whether the original exception should be thrown or the TargetInvocationException. For backward compatibility the default value will be false.
Consider the following method that needs to be tested: property:

public class Foo
    private void ThrowsException()
        throw new NotImplementedException("There is no implementation.");

And here is how a test will look using the new RethrowOriginalOnCallMethod property.

public void PrivateAccessor_CallMethod_ThrowsException()
    var instance = new PrivateAccessor(new Foo());
    instance.RethrowOriginalOnCallMethod = true;

JustMock Stopped Working in Visual Studio 2019 Versions Greater than 16.2

With Visual Studio 2019 version 16.2 the test window and the whole test execution process has undergone a major overhaul. This affected JustMock in an unpleasant way. It literally stopped working the moment you update your Visual Studio to 16.2 or greater version. Even the resulting error of disabled profiler was misleading as enabling or disabling the profiler had no effect on the matter.
Fortunately, we had a very constructive discussion with Microsoft and together we came to a solution that provides full support of JustMock in VS2019 16.2+.

Sign Up for the Webinar

To see the new release in action, please join us on the Telerik R3 2019 webinar, on Wednesday, October 2, 2019 11:00 AM ET - 12:30 PM ET.

Save My Seat

Share Your Feedback

Feel free to drop us a comment below sharing your thoughts. Or visit our Feedback portal and let us know if you have any suggestions or if you need any particular features.

Try out the latest:


You can also check our Release History page for a complete list of the included improvements.

Mihail Vladov
About the Author

Mihail Vladov

Mihail Vladov is a Software Engineering Manager at Progress. He has more than a decade of experience with software and product development and is passionate about good software design and quality code. Mihail helped develop the WPF controls suite and Document Processing libraries which are used by thousands of developers. Currently, he is leading the JustMock team. In his free time, he loves to travel and taste different foods. You can find Mihail on LinkedIn.

Related Posts


Comments are disabled in preview mode.