6

During this semester my professor tried to convince us why is good to use unit tests during development, why is it good to validate data(Microsoft Application Block) and also he told us about using mocking(RhinoMocks) in order to test our methods when we didn't had access to a database.

I had to do some unit tests with mocking and in order to make them work i had to create by hand the objects hierarchy that was needed in order to test my method(It took me a while to write everything i needed).

The question that i want to put: in production is it useful to use mocking? Should i use it every time i have the chance? And also the effort made to write everything in order to test a method with mocks does it pay off?

thank you

razlebe
  • 7,134
  • 6
  • 42
  • 57
Sorin Antohi
  • 6,145
  • 9
  • 45
  • 71
  • Duplicate of "Why Create Mock Objects?" (http://stackoverflow.com/questions/1414032/why-create-mock-objects). Sorin, you ought to check that question out - it has several great answers. Having said that, mocking frameworks have easily saved me dozens (maybe hundreds) of hours. – Jeff Sternal Feb 19 '10 at 15:20
  • Thank you Jeff, read the answers from that question really useful! – Sorin Antohi Feb 19 '10 at 15:24

5 Answers5

1

Yes, using mock objects as one among your many unit testing tools is definitely a worthwhile endeavour.

However, it goes best with Test-Driven Development because the tests drive the design. When you begin to feel the pain of tightly coupled code because you have to maintain deeply nested structures, you know it's time to refactor to a more loosely coupled API.

Mark Seemann
  • 225,310
  • 48
  • 427
  • 736
  • TDD was also a subject of discussion during this semester course. i found it hard not to jump over the steps specified. So for short i need to feel like a fish in the water when it comes to testing(TDD, mocking) in order to grow. – Sorin Antohi Feb 19 '10 at 15:14
  • "one among your many unit testing tools". Just out of interest, what other tools are you using besides RhinoMocks and msTest/nUnit to help with your tests?? – Kye Oct 14 '10 at 23:48
  • My UT stack is xUnit.net, Moq and AutoFixture. Add to this whatever custom 'tools' created for specific situations - here's an example: http://blog.ploeh.dk/2009/08/06/AFluentInterfaceForTestingINotifyPropertyChanged.aspx – Mark Seemann Oct 15 '10 at 05:08
1

Mocks solve the following problems:

  • Without them your tests end up testing more than your code under test. So if there is a bug in the dependency that will get flagged up in your test (or even worse, it may cover up a bug in your code)
  • The integration points may return different results at the time you write tests compared to the time the tests are run due to an external dependency change (think - change in database state)
  • When integrating with external systems your tests will run a lot slower. This will cause other developers to run them less often and hence decrease the value of your tests
  • When used correctly they make tests simpler to read and intent of your module more obvious.
Russell Giddings
  • 8,731
  • 5
  • 34
  • 35
  • "So if there is a bug in the dependency that will get flagged up in your test (or even worse, it may cover up a bug in your code)" I would argue that this isn't a problem but rather an asset. If there's a bug in a dependency which causes your test to fail (given the test is written correctly) then your system has a bug in it and it needs to be addressed. I would argue that this is actually a shortfall of mocks - as they do not provide as much confidence about system correctness compared to component/integration tests. – Aidan Do Jun 03 '22 at 00:04
0

There is no right anwser to this one. Mocking frameworks (like RhinoMocks) can do some powerful stuff. My personal choice is that I like to roll my own mock objects. If I find this hard I use it as a smell that I have something wrong in my design.

I do use mocks on legacy code when it is either really really difficult or lots of code to do the setup of my unit tests.

I accept that there is more that I could learn on using mocking frameworks.

btlog
  • 4,760
  • 2
  • 29
  • 38
0

For my current project, I still write stub objects for my unit tests most of the time. Only once I really felt the need for a mock object and I wrote it manually.

I'd like to advise to take this on very pragmatically: if you need mock objects a lot, consider learning a mocking framework (this also comes with a price of course), otherwise use stub objects or your occasional hand-written mock object.

Gerrie Schenck
  • 22,148
  • 20
  • 68
  • 95
0

I'm not sure if RhinoMocks has the same capability but with moq you can get what you need from an object hierarchy without actually having to create it.

Ie. If your method accepts an IUser and needs to get access to IUser.Person.ContactInfo.PhoneNumbers.BusinessPhone you don't need to create the entire graph. You only need to do this:

var mockUser = new Mock(); mockUser.Setup(u => u.Person.ContactInfo.PhoneNumbers.BusinessPhone).Returns("555-1212");

This can be valuable but can also lead to poor design as Mark mentioned above.

devlife
  • 15,275
  • 27
  • 77
  • 131