i’ve started unit testing a while ago and as turned out i did more regression testing than unit testing because i also included my database layer thus going to the database verytime.
So, implemented Unity to inject a fake database layer, but i of course want to store some data, and the main opinion was: “create an in-memory database”
But what is that / how do i implement that?
Main question is: i think i have to fake the database layer, but doesn’t that make me create a ‘simple database’ myself or: how can i keep it simple and not rebuilding Sql Server just for my unit tests 🙂
At the end of this question i’ll give an explanation of the situation i got in on the project i just started on, and i was wondering if this was the way to go.
Michel
Current situation i’ve seen at this client is that testdata is contained in XML files, and there is a ‘fake’ database layer that connects all the xml files together.
For the real database we’re using the entity framework, and this works very simple.
And now, in the ‘fake’ layer, i have top create all kind of classes to load, save, persist etc. the data.
It sounds weird that there is so much work in the fake layer, and so little in the real layer.
I hope this all makes sense 🙂
EDIT:
so i know i have to create a separate database layer for my unit test, but how do i implement it?
Uhhhh…… If you’re storing all your test data in XML files. You’ve just changed one database for another. That is not an in memory database. In PHP you would use something like this.
You notice that all my data is stored in a memory array and is retrieved from a memory array. This is a simple In Memory Database.
IMHO, if you’re using XML to store test data then you really haven’t disconnected the dependencies from the model and the database effectively. No matter how complex your business rules are, when they touch the database, all they really are doing is CRUD (create, retrieve, update, and delete) functionality.
If you what your dealing with in the model is multiple objects from the database then maybe you need to compose all those objects into a single object and have the model use that one object. An example would be an
ordercomposed of products. Don’t be retrieving products then saving products. Retrieve orders then save orders and have your model work on orders. The model shouldn’t know anything about products.This is called granularity of abstraction.
[Edit]
There was a very good question in the comments. When testing with an In Memory Database we don’t care about how the select works in a database. The controller, first off, has to have functionality on the database to count the number of possible records that could be accessed for paging. The IMDb (in memory database) should just send a number. The controller should never care what that number is. Same with the actual records. Hopefully all your controller is doing is displaying what it gets back from the IMDb.
[EDit]
You should never be unit testing your controllers with a live model and imdb. The setup code for the imdb will have a lot of friction. Instead when unit testing a controller, you need to unit test a mock, stub, fake model. The best use of an imdb is during an integration test or when unit testing a model. Isn’t an imdb a fake?
My scenario is:
product.get(5,10). The return data will be encoded JSON.The model will be responsible for forming the JSON from retrieving information from the gateway to the database. The gateway is just a facade over the database. I’m a mocker so my gateway is a mock not an in memory gateway.
You will notice that with this unit test that I’m not concerned what the data looks like.
$skusdoesn’t even look anything like that actual table schema. Just that I return records. Here is the actual code for the model:The first part of the method breaks the individual parameters from the
$parameterListthat I get from the get request. The rest are calls to the gateway. Here is one of the methods: