Can a Mock framework do this for me ?

Question

Hello,

I am a bit confused

from wiki: "This means that a true mock... performing tests on the data passed into the method calls as arguments."

I never used unit testing or mock framework. I thought unit tests are for automated tests so what are mock tests for?

What I want is a object replacing my database I might use later but still dont know what database or orm tool I use.

When I do my programm with mocks could I easily replace them with POCO`s later to make entity framework for example working pretty fast?

edit: I do not want to use unit testing but using Mocks as a full replacement for entities + database would be nice.

Answer 1

Yes, I think you are a bit confused.

Mock frameworks are for creating "Mock" objects which basically fake part of the functionality of your real objects so you can pass them to methods during tests, without having to go to the trouble of creating the real object for testing.

Lets run through a quick example

Say you have a 'Save()' method that takes a 'Doc' object, and returns a 'boolean' success flag

public bool Save(Doc docToSave(){...}

Now if you want to write a unit test for this method, you are going to have to first create a document object, and populate it with appropriate data before you can test the 'Save()' method. This requires more work than you really want to do.

Instead, it is possible to use a Mocking framework to create a mock 'Doc' object for you.

Syntax various between frameworks, but in pseudo-code you would write something like this:

CreateMock of type Doc
SetReturnValue for method Doc.data = "some test data"

The mocking framework will create a dummy mock object of type Doc that correctly returns "some test data" when it's '.data' property is called.

You can then use this dummy object to test your save method:

public void MyTest()
{
    ...
    bool isSuccess = someClass.Save(dummyDoc);
    ...
}

The mocking framework ensures that when your 'Save()' method accesses the properties on the dummyDoc object, the correct data is returned, and the save can happen naturally.

This is a slightly contrived example, and in such a simple case it would probably be just as easy to create a real Doc object, but often in a complex bit software it might be much harder to create the object because it has dependencies on other things, or it has requirements for other things to be created first. Mocking removes some of that extra overload and allows you to test just the specific method that you are trying to test and not worry about the intricacies of the Doc class as well.

Mock tests are simply unit tests using mocked objects as opposed to real ones. Mocked objects are not really used as part of actual production code.

If you want something that will take the place of your database classes so you can change your mind later, you need to write interfaces or abstract classes to provide the methods you require to match your save/load semantics, then you can fill out several full implementations depending on what storage types you choose.

Answer 2

I think what you're looking for is the Repository Pattern. That link is for NHibernate, but the general pattern should work for Entity Framework as well. Searching for that, I found Implementing Repository Pattern With Entity Framework.

This abstracts the details of the actual O/RM behind an interface (or set of interfaces).

(I'm no expert on repositories, so please post better explanations/links if anyone has them.)

You could then use a mocking (isolation) framework or hand-code fakes/stubs during initial development prior to deciding on an O/RM.

Unit testing is where you'll realize the full benefits. You can then test classes that depend on repository interfaces by supplying mock or stub repositories. You won't need to set up an actual database for these tests, and they will execute very quickly. Tests pay for themselves over and over, and the quality of your code will increase.