I have 3 questions regarding using unit tests that use mocks, and this is a cross post from a thread that I posted on CodePlex. I am curious to see what you guys think.

Question Summary:

• Is it correct that mocks are just testing the published / public interfaces of the objects that the mock object mimics?

• Aside from proving that you have invoked the methods and members of your mock classes, how valuable are unit tests that work with mocks? (Afterall the mock code doesnt interact with the "real code")

• should we be using unit tests that work with the "real" code in addition to unit tests that work with mock objects?

Re-Post of Original Thread I have been evaluating WCSF for use withing my organization. At my company we use CI and TDD practices and I see the value in unit tests and code coverage analysis, etc. etc. I have never been a real fan of MVP / MVC because of all of the moving parts compared to what "really" gets re-used. A Microsft MVP told me that the "real" purpose of the MVP & MVC patters was to allow us to unit test more of the code and to allow us to switch between WinForms, WebForms, and CompactFramework with minimal modifications to code. So, once again, here I am reviewing the latest and greatest from the P&P team.

In my review of the Global Bank Commercial EBanking solution, I see that mocks are used heavily. I am not too sure if I am missing the point but it seems to me that mocks are just testing the published / public interfaces of the objects being created in WCSF (i.e., views, presenters, controllers, services, module initializers, etc.).

Assuming that this observation is correct, I have concluded that the "real" functionality that is being delivered is never tested with mocks. Is this a correct conclusion? The reason that I have come to this conclusion is that I havent found many unit tests that deal with the "real" code, (i.e. the functional code that lives in the NON-mock classes).

So I guess my real question is this... aside from proving that you have invoked the methods and members of your mock classes, how valuable are unit tests that work with mocks? My reasoning behind this question is that, just because our executing code hits the mock classes, if the code that lives in the real object doesnt work then we dont have functionality that is deliverable.

My second question is this... should we be using unit tests that work with the "real" code in addition to unit tests that work with mock objects?

Thanks for your guidance, opinions, and comments.

DD,

Disclaimer: I'm relatively new to using mock objects.

I generally use mock objects for two purposes:

1. To act as a placeholder in my unit tests until the actual objects have been coded and can be tested. So once the "real" objects are finished, I change the mock implementation in my units tests for the real implementation(s).

2. Very similar to #1, but sometimes there is a dependency between an object I am testing (TestObject) and another object that implements a specific interface (IDependent), and I want to test TestObject without using a real implementation of IDependent. In this case, I would never have to swap the implementation, as it's not IDependent I am testing. (A good example of this is mocking up a view to test the presenter in a Model-View-Presenter scenerio).

I currently just roll my own mock objects--I haven't delved into RhinoMocks or any other mock object framework yet.

Phil

Devildog74 wrote:

Question Summary:

• Is it correct that mocks are just testing the published / public interfaces of the objects that the mock object mimics?

No, you are not testing the mock. You are mocking a dependent object for the object that you are actually testing. For example, you could use a Mock DAL object rather than the actual DAL object when testing a business object.

Devildog74 wrote:

[*]Aside from proving that you have invoked the methods and members of your mock classes, how valuable are unit tests that work with mocks? (Afterall the mock code doesnt interact with the "real code")

No, the real code interacts with the mocks, and it is the "real" code you are testing. But, when you test the real code you want to ensure that it is doing what it is supposed to, such as raising an event or calling a dependent object, etc.

Devildog74 wrote:

should we be using unit tests that work with the "real" code in addition to unit tests that work with mock objects?

You certainly will test all of your public APIs. But, you would test those lower level items with seperate unit tests. For example, you will Unit test your DALs, possible mocking the database. Then, you will unit test your business layer, mocking the DAL. Then, you will unit test your presenters mocking your business objects. The whole point of mocks is to test each class in isolation. Using mocks ensures that you know when your object under test delegates to a dependent object exactally what response that object will supply. And, the mocks allow you to go one step further to test that interaction. For example, you can test to ensure that your business object called the GetAllCustomers method on the DAL passing "true" for example.

Devildog74 wrote:

My second question is this... should we be using unit tests that work with the "real" code in addition to unit tests that work with mock objects?

I feel you should be testing every public method of your apps code striving for 100% code coverage meaning writting tests for each method that cover every code patch based on passing the correct parameters, etc.

BOb

Bob, you write "The whole point of mocks is to test each class in isolation. Using mocks ensures that you know when your object under test delegates to a dependent object exactally what response that object will supply. And, the mocks allow you to go one step further to test that interaction."

This makes sense now.

Thanks for the insight.