Andrew Stopford's Weblog

poobah

News

Articles

MbUnit Folks

Old Blogs

Dependency Injection/Mocks, what's best?

One of things I am still learning about is the use of DI or Mocks in my coding toolbox. What's confusing me is how to avoid creating too much complexity in my application to achieve testability. What I would love to see is concrete examples of DI/Mocks in use against say business objects that show how to achieve testability against my objects. Any thoughts, links to examples and other useful stuff would be handy on my journey.

Update: James Shore does a good job of explaining DI.

Update: Fredrik Normén answers my post with some examples, thanks Fredrik.

Comments

Messaoud OUBECHOU said:

Well,
I have asked myself the same question several month ago.
Here is the link for a simple / beginner exemple :
http://fr.www.prettyobjects.com/content/en/POCMock/Walkthroughs/WT1/POCMockWalkthrough1.html

The fmwk is POC Mock, from PrettyObject vendor.

Hope it helps,
mess
# June 12, 2006 11:04 AM

Julien Couvreur said:

Actually, testability is a great indicator of good design.

And having tests and unittests means that you'll have less bugs, you'll be able find the root cause for bugs more easily and find when you break some code by accident.

In my opinion, a common use for Mock objects is when you have a DB layer to persist your business objects. That means that to test the business logic, you may need that DB layer with an actual DB. With Mock objects, you don't need that DB and you'd create a mock DB layer...

An argument for testability and introduction to mock objects:
http://www.netobjectives.com/streamzines/MockObjectsAndMockTurtles/player.html
# June 12, 2006 11:46 AM

Fredrik Normén said:

Hi,

I wrote an "answer´" to this post on my blog:

http://fredrik.nsquared2.com/viewpost.aspx?PostID=364&showfeedback=true
# June 12, 2006 1:30 PM

Mike Gale said:

The issue with mocking is that many implementations only work with some code.  Forces you to code differently.

If it's essential then so be it but the ideal is not to refactor (and maybe deform) your code too much for testability.

I like the look of POCMock, though I've never tried it.  Seems like a good way to go.
# June 12, 2006 4:47 PM

RoyOsherove said:

I have code samples from my "Design for testability session in DevDays" here:
http://weblogs.asp.net/rosherove/archive/2006/03/13/440121.aspx
and also this article might help:
http://weblogs.asp.net/rosherove/articles/Design4Tesatbility1.aspx
# June 12, 2006 6:47 PM

hammett said:

Since SoC is applied you'd have a testable design.
See http://www.codeproject.com/cs/design/introducingcastle.asp
# June 12, 2006 6:56 PM

Jason Haley said:

# June 13, 2006 9:38 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)