views:

118

answers:

5

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

A: 

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
+1  A: 

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
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.
SorinA.
"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??
ForeverDebugging
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
A: 

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
A: 

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
A: 

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