Question

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.