Ok, I know I promised I would post about Virtual Mocks but to be honest I am not sure I myself fully understand the difference or need. Mock objects are easy to understand, but I have yet to find two people that agree on the definition of Virtual vs. "regular" Mocks.

Wikipedia has entries for both Mocks and Virtual Mocks, but at least at the time I write this there was little to no content on the Virtual Mock entry. The main difference would appear to be that Virtual Mocks can Mock a concrete class, while normal Mocks are used to simulate the interface only.

More on this as I learn more. But my use of Mocks in TDD has been pretty much limited to interface level work. There is a huge and at times, nasty debate in the blogosphere relating to Mocks, particularly as they relate to coupling issues, Dependency Injection (DI) and Inversion of Control (IoC) issues. Which also ties into the growing debate on "design for testing", which means that you write your code to facilitate testing from the start.

I honestly don't have the required background to register a viable defensible opinion on all of these issues. What I can say is that using TDD and Mock's has enabled me to produce better quality software, faster than I ever have before. With fewer debugging sessions, and as an added benefit it tends to make me write code that is easier to refactor later to introduce new features etc.

One of my most memorable moments in my journey along the TDD path of discovery was when I had to add significant new functionality to an existing application that I had written. The application had existing tests, with probably close to 80% coverage.

I made the first round of changes, ran the tests, had two failures, refactored the new code to get the tests to pass, added a couple of new tests related to the new functionality, fired the tests one last time, all green! Turned the code, with confidence, over to QA and testing and was done! It was a personally very satisfying moment. Previously I would have held onto the code for at least another two or three days trying various combinations of simulations and debug stepping and then been still unsure of the state when I turned it over.

Mocks come in very handy for me when I want to decouple the system under test from dependencies that are expensive (Database calls, Web Service Calls), or ones that don't exist in any form except for production. (I have worked for clients that could not or would not set up a complete DEV/TEST/PROD triad of environments, and in some cases, some systems only existed as production instances.)

Remember, when you are testing and developing you are testing your code, not performing integration testing of the whole system. That comes later.

Mocks also come in handy for cases when you need to test your codes response to what is in essence a "black box call" to a component or system for which you don't have code, or don't have the access etc. In short Mocks help me focus on my code and the system under test and not someone else's.

In an upcoming post I will show some examples of how and when I have used Mocks. And attempt to explain the thinking I went through in deciding to use a Mock, and how to implement the Mock etc.

Meantime, keep the questions coming!

Cheers,

Robert Porter