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.
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:
privatevoidDoPrivateGeneric<T>(T arg) { thrownewNotImplementedException(); }Here is how a mock for that method could look like:
[TestMethod] publicvoidShouldInvokeNonPublicGenericMember() { Foo foo = newFoo(); boolcalled = false; // Arrange Mock.NonPublic .Arrange(foo, "DoPrivateGeneric", newType[] { typeof(int) }, 10) .DoInstead(() => called = true); // Act foo.DoPublicGeneric<int>(10); // Assert Assert.IsTrue(called); }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.
[TestMethod] publicvoidShouldMockInternaldotNETClassWithArgs() { // Arrange stringtypeName = "System.Net.WebSocketHttpRequestCreator"; var httpRequestCreator = Mock.Create(typeName, (config) => config .CallConstructor(newobject[] {true})); Mock.NonPublic.Arrange(httpRequestCreator, "Create", ArgExpr.IsAny<Uri>()) .CallOriginal() .MustBeCalled(); // Act System.Net.IWebRequestCreate iWebRequestCreate = (System.Net.IWebRequestCreate)httpRequestCreator; var result = iWebRequestCreate.Create(newUri("https://www.telerik.com")); // Assert Mock.Assert(httpRequestCreator); Assert.AreEqual(newUri("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:
publicclassFoo { privatevoidThrowsException() { thrownewNotImplementedException("There is no implementation."); } } And here is how a test will look using the new RethrowOriginalOnCallMethod property.
[TestMethod] [ExpectedException(typeof(NotImplementedException))] publicvoidPrivateAccessor_CallMethod_ThrowsException() { var instance = newPrivateAccessor(newFoo()); instance.RethrowOriginalOnCallMethod = true; instance.CallMethod("ThrowsException"); } 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.
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.