I am currently writing some training material for a client on mocking showing how life is so much easier if software is designed with testing in mind. As part of this material I showing that though we aim for nice design patterns which allow testing we have to deal with legacy systems that were not designed this way. However, there are tools that allow us to write unit tests for poorly designed (with testing in mind) legacy systems, specifically Typemock Isolator. Using Isolator means we can write tests that we can use to make sure the code is not broken whilst refactoring to new structures.
Just to add a bit of interest the material needs to be in VB.NET not my usual language, so I have spent some time porting the demos I use at conference sessions on Isolator from C# to VB.NET.
Whilst doing this I had to get used to the fact that the Typemock syntax used in VB in a different C#. Using ‘using’ blocks for most things, so the C# lamda expression syntax
Isolate.Verify.WasCalledWithExactArguments(() => fake.IsEmailAddessInDB.SendEmail(“firstname.lastname@example.org"));
Using AssertCalls.HappenedWithExactArguments() fake.IsEmailAddessInDB("email@example.com") End Using
But this is not an issue I had. The problem was that I was trying to show a real worst case where you need to mock private methods. One the dirtiest tricks of Isolator. Setting up the non-public Isolator behaviour is easy in VB
Isolator.VisualBasic.NonPublicWillReturn (fakeProcessor, "GetOrderForClient",fakeOrder) Isolator.VisualBasic.NonPublicWillBeIgnored(fakeProcessor, "SendEmail")
Problem is there seems to be no non-public verify methods in the Isolator VB syntax. I found an old forum post on the subject, but nothing since. However, I did find answer hinted at in another post, but it might be a bit obscure if you are new to Isolator. The process is as follows
- In your test project as well as the references to Typemock and Typemock.Isolator.VisualBasic also add one to the C# Isolator API Typemock.ActAssertArrange
- You can now use the C# methods to do the job. So the verification becomes
TypeMock.ArrangeActAssert.Isolate.Verify.NonPublic.WasCalled(fakeProcessor, "GetOrderForClient") TypeMock.ArrangeActAssert.Isolate.Verify.NonPublic.WasCalled(fakeProcessor, "SendEmail").WithArguments(“firstname.lastname@example.org")
Now don’t think for a second I am suggesting it is a good idea to be mocking private methods, or frankly using any of the Isolator dirty tricks. I still think if you find yourself using any of the Isolator features that all the other mocking frameworks cannot do then you seriously need to look at your code bases design. However, there are just cases when you can’t change the design and the use of Isolator is the only option you have if you wish to write any tests. In these cases it is great to a tool to give at least some test coverage.