Dependency Injection with Ninject and Mocking with MoQ

Today it’s my great pleasure to lead the discussion about Dependency Injection with Ninject and Mocking with MoQ at the SEVDNUG.

Our purpose as software developers is to orchestrate together loosely coupled, well tested components.  Yet far too often, our code turns into a big ball of mud.  These two tools and their supporting techniques can create loosely coupled, eagerly testable code that will make you much more productive.

Our starting place is this, an n-tier app with hard-coded dependencies.  This is very hard to unit test.  I grant there’s good separation of concerns here, and that typically that’s harder than it looks.  After a brief discussion of the architecture of this app, we’ll look for seams in the code — places where we can insert interfaces and separate the dependencies.  We’ll make the adjustments with the help of Resharper, then get Ninject to wire up the dependencies for us.  With dependencies solved, we’ll look at unit testing various pieces (time permitting).  We’ll instantiate the code under test, and mock the dependencies using MoQ.  Once we’re done, we’ll end up with something similar to this, an app with loosely bound dependencies, a clean separation of concerns, and good test coverage.  Even more important, we will understand the purpose and benefits of Dependency Injection, and have a firm, practical grasp of how to accomplish it.  We’ll also have a firm understanding of mocking, and practical tools at hand to make unit testing easy.

Where can you go from here?  Let’s look at unit testing routes, integration testing, continuous integration, etc.  The sky’s the limit.

Rob