The first major release of 2013 (specifically, the 2013-Q1 release) of JustMock brought us Profiled Automocking! If you aren’t familiar with the concept of automocking, please read my prior post that goes into great detail on the subject. But in short, auto mocking containers are designed to reduce the friction of keeping unit test beds in sync with the code being tested as systems are updated and evolve over time.
Quite often, we find that older code bases weren’t written with SOLID principles in mind. This typically means that instead of writing code that calls into interfaces, concrete objects are utilized. This can make it extremely difficult to write isolated unit tests. Fortunately, JustMock enables isolation of all types of dependencies, including (but not limited to) concrete, sealed, static, and private classes/member.
For example, if you look at the services shown in Listing 1 and the Login class that uses these services in Listing 2, typical unit testing techniques (including non-elevated automocking) do not work. The classes could be marked virtual, have their interfaces extracted, or a number of other fixes, but changing code before it’s under test can be a risky endeavor.
public class LoggingService
public void LogInvalidLogin(string userName, string password)
throw new Exception("Logging Service - Log Invalid Login");
public class UserValidationService
public int ValidateUser(string userName, string password)
throw new Exception("User Validation Service - Validate User");
Listing 1 – Services used by the Login Class
public class Login
private UserValidationService _userValidationService;
private LoggingService _loggingService;
public Login(UserValidationService service, LoggingService mockLoggingService)
this._loggingService = mockLoggingService;
this._userValidationService = service;
public bool LoginUser(string userName, string password)
int userID = _userValidationService.ValidateUser(userName, password);
if (userID == 0)
Listing 2 – Login Class
Dealing with Legacy Code is JustMock’s wheelhouse. Just as in non-elevated automocking, we pass the system under test (in our case the Login class) into the automocking container, arrange the dependency (or dependencies) that matter, call our action, and assert the results. The Happy Path and Sad Path tests are shown in Listing 3.
public class LoginTests
public void ShouldLoginWithValidUserCredentials()
var userName = "Bob";
var password = "password";
var userID = 5;
var container = new MockingContainer<Login>();
x => x.ValidateUser(userName, password))
bool result = container.Instance.LoginUser(userName, password);
public void ShouldLogInvalidLoginAttempts()
var userID = 0;
x => x.LogInvalidLogin(userName, password))
Listing 3 – Elevated Automocking with JustMock
For a more in depth look at automocking, please refer to my prior post here. Simply put, with elevated automocking, testing even legacy code can be a breeze! Download your copy today and start testing immediately.
Technorati Tags: JustMock,Tests,Mock,MockingContainer,Telerik,JustCode,JustTrace,JustDecompile,skimedic,Dependency Inversion Principle, Unit Tests
Philip Japikse is an international speaker, a Microsoft MVP, ASPInsider, INETA Community Champion, MCSD, CSM/ CSP, and a passionate member of the developer community. Phil has been working with .Net since the first betas, developing software for over 20 years, and heavily involved in the agile community since 2005. Phil also hosts the Hallway Conversations podcast (www.hallwayconversations.com) and serves as the Lead Director for the Cincinnati .Net User’s Group (http://www.cinnug.org). You can follow Phil on twitter via www.twitter.com/skimedic, or read his personal blog at www.skimedic.com/blog.