Unit testing with mock objects - I fail to see the point

Question

Hi,

Quite often, complex software includes unit tests where all the important stuff is mocked out. For example database access in the unit test is mocked out so that it's just a simulation. Whats up with that? I cannot test my car where I yank out the engine and replaces it with a MP3 player that sounds like my car. What kind of test is that? You get my meaning? :)

I really would like to understand the purpose of testing with mock objects - please someone explain this? If the mock-out really only means that I'm testing 2% of my WCF service for example - then why not test those 2% specifically using REAL unit tests, targeting only those 2%?

Edit:
Just to make it clear: I think unit tests using mock objects is an anti-pattern so to speak. Mocking hides real-life derived effects, which means that unit testing with mock objects gives a false indication of how things behave in production - at best.

--
Werner

Answer 1

You are right, unit test won't test how the system will behave in production.

But that's not what unit tests are intented for. To test the production behavior, you write functional/integration/end to end tests.

Unit tests are written by developers to test their idividual piece of code without being dependent on some other piece of code. Thats where mocks are useful.

Thanks,

Anuj

---

http://www.anujchaudhary.com

Answer 2

The problem with testing Live things as they are in production is that they're usually not fast, not easily reproduceable and often hard to run in parallel. This all makes it a general pain to run them often to ensure that behavior of the code hasn't changed.

And that's where one important thing lies. A unit test verifies the behavior of the code. And just that.

The problem with that is that if your code isn't really object oriented and is abstracted toward behavior, then you will write a lot of micks and stubs to tets very thin layers of code each and every time. And it's much harder to test things without all these mocks and stubs. If your code is abstracted on the behavior side and it's clear how these things should work (you have clear contracts) and your exception handling strategy is well defined etc. (you're writing high quality code), then it's much easier to write good unit tests that really add benefit.

If you webservices are not much more than a thin wrapper around a EF Query, or a simple pass through to some other thin data layer which then executes a stored procedure, then you won't find much use for real unit tests. But that is basically an indication that you're not really building code which is easily extensible and designed for change in the long run.

---

My blog: blog.jessehouwing.nl

Answer 3

If you webservices are not much more than a thin wrapper around a EF Query, or a simple pass through to some other thin data layer which then executes a stored procedure, then you won't find much use for real unit tests. But that is basically an indication that you're not really building code which is easily extensible and designed for change in the long run.

---

My blog: blog.jessehouwing.nl

Not sure I understand that generalization...are you saying that the web service isn't implemented correct? Or that the logic that uses the webservice isn't correct?

--
Werner

Answer 4

I wouldn't say wrong or incorrect, but not very Object Oriented and not very re-usable. And usually not very testable. So from that perspective you might call it wrong

---

My blog: blog.jessehouwing.nl

Answer 5

I wouldn't say wrong or incorrect, but not very Object Oriented and not very re-usable. And usually not very testable. So from that perspective you might call it wrong

---

My blog: blog.jessehouwing.nl

Alright I think I understand you now, though I'm not sure I agree with that generalization. There would be a lot of scenarios that does just wraps something else...and still being pefectly valid solutions. Perhaps a better way would be, to think of unit tests as a tool for testing domain invariants? Just a thought...

--
Werner