Announcing JustMock Q2 2013

Another release is in the books, and the development team delivers another awesome set of features for JustMock.  In addition to Mocking By Example, there are several new features, enhancements to existing features, and continued improvement of JustMock’s compatibility with other  profiled applications and common build servers.

Future Constructor Mocking - New

Future mocking is a technique to mock a class that is instantiated in the system under test.  Long a feature of JustMock, future mocking got a well deserved enhancement this release.

Future Mocking – A Review

Take the Login class shown in Listing 1.  The UserValidationService is created in the class constructor, and not passed in through dependency injection.  Future Mocking enables you to mock a class that is created in the “future”, in other words, after the test is arranged.

public class Login
 
{
 
 private UserValidationService _service;
 
 
 public Login()
 
    {
 
        _service = new UserValidationService();
 
    }
 
 public bool LoginUser(string userName, string password)
 
    {
 
 return (_service.ValidateUser(userName, password)) != 0;
 
    }
 
}
 

Listing 1 – The System Under Test

To replace the call of ValidateUser on the instance created in the system under test, we apply the IgnoreInstance() method in the arrangement of the class in the test, as in Listing 2.  Note that we don’t create a mock of the UserValidationService, but instead create a concrete instance when arranging the test.

[Test]
 
public void ShouldMockInstanceCreatedInSUT()
 
{
 
    var service = new UserValidationService();
 
    var userName = "Bob";
 
    var password = "password";
 
    service.Arrange(x => x.ValidateUser(userName, password))
 
            .IgnoreInstance()
 
            .Returns(5);
 
    var sut = new Login();
 
    var result = sut.LoginUser(userName, password);
 
    Assert.IsTrue(result);
 
}
 

Listing 2 – Future Mocking the dependency

Future Constructor Mocking

Sometimes, this isn’t enough.  If you have a dependency class that is doing work in the constructor (for example, trying to connect to a database), this can skew the results of your test.  The least it will do is cause performance issues.

The answer is to not execute the constructor.  In order to do this, we add an arrangement with the DoNothing() method to the instantiation of the dependency, as shown in Listing 3.  The arrangement simple states “When this class is created, do not execute the constructor”.

[Test]
 
public void ShouldMockConstructorForFutureInstances()
 
{
 
 // Directly arranging the constructor 
 
    Mock.Arrange(() => new UserValidationServiceCtor())
 
        .DoNothing();
 
 // This will not throw an exception 
 
    var service = new UserValidationServiceCtor();
 
    var userName = "Bob";
 
    var password = "password";
 
    service.Arrange(x => x.ValidateUser(userName, password))
 
            .IgnoreInstance()
 
            .Returns(5);
 
    var sut = new Login();
 
    var result = sut.LoginUser(userName, password);
 
    Assert.IsTrue(result);
 
}
 

Listing 3 – Disabling the constructor in the dependency

JustMock has long been the savior to developers trying to test hard to test code, and this adds to the arsenal of awesome capabilities!

Simplified MsCorLibMocking – Improved

Dealing with classes in the MsCorLib (such as Date, File, etc.) has always been problematic for developers writing unit tests.   While the capability has been in JustMock for many releases to mock out these objects, this release greatly simplifies the mechanism to do so.  Instead of using the Mock.Replace syntax (or class attributes), you can now use the simple Mock.Arrange syntax used for mocking other classes.

Take the system under test shown in Listing 4. It uses the DateTime class to set the LastLoginTime for the user. (Ignore the return true – I made this example simple to show the MsCorLib mocking).

public class Login
 
{
 
 public DateTime LastLoginTime { get; private set; }
 
 
 public bool LoginUser(string userName, string password) 
 
    {
 
 this.LastLoginTime = DateTime.Now;
 
 return true;
 
    }
 
}
 

Listing 4 – System Under Test Using MsCorLib

Without mocking our DateTime assignment, you need to reset the system clock in order to make a test repeatable. The new, simplified syntax is shown in Listing 5. With one very simple line of code the DateTime problem is solved!

[Test]
 
public void ShouldMockMSCorLibNewWay()
 
{
 
    Mock.Arrange(() => DateTime.Now)
 
        .Returns(new DateTime(1900, 4, 12));
 
    var sut = new Login();
 
    sut.LoginUser("Bob", "Password");
 
    Assert.AreEqual(1900, sut.LastLoginTime.Year);
 
    Assert.AreEqual(4, sut.LastLoginTime.Month);
 
    Assert.AreEqual(12, sut.LastLoginTime.Day);
 
}
 

Listing 5 – Unit Test Mocking DateTime

Silverlight Elevated Mocking - New

With this release, you can now use elevated mocking for testing Silverlight.  If you need elevated mocking for Silverlight, the development team has written a very detailed Help topic that can be found here.

Compatibility with other profiled tools – Improved

Many products on the market use the .NET profiler, and JustMock is one of them.  It’s how elevated mocking is accomplished. The team is continuously improving the ability for these products to work together.  This release is no different, adding NCover, dotCover and more to the list of products that can play nicely with JustMock in elevated mode.

Ease of use and compatibility with build systems – Improved

The JustMock developer license also comes with a build server license.  We’ve been hard at work making sure that elevated mocking works seamlessly with the most popular build servers, and that the documentation makes it a breeze to configure.  This quarter brings Microsoft’s TFS, CruiseControl.NET, Team City, Jenkins, and more into the fold, giving you even more options for how you build your software!

Summary

This release is again jammed packed with new features and many updated features. If you haven’t tried JustMock download it now. The trial is free!

Follow @skimedic