Home » Posts tagged "dependency injection"

Dependency Injection Frameworks Are NOT Dependency Injection

land-0148

As you start your journey down the road of Unit Testing you will discover that part of what makes code testable is this concept of Dependency Injection.  As you explore further, you will see people mentioning various Dependency Injection frameworks. You may naturally assume that to implement Dependency Injection, you will need to select an use a Dependency Injection framework.

But, Dependency Injection has nothing to do with using a Dependency Injection framework.  The frameworks are there because:

1.  much of our existing code is code that has too many dependencies and the framework helps us break those dependencies without having to refactor too much of our code and

2. to give us a way to easily swap out one object for another when our code is structured in such a way as to not have dependencies at all.

Continue reading “Dependency Injection Frameworks Are NOT Dependency Injection”

Software Architecture without Test Driven Development is DANGEROUS!

TDD Impacts Software ArchitectureI’ve had two incidents recently that have shown me how TDD impacts Software Architecture.  Both of these are with code I’m working on.

What Software Architecture Might Do

Software architecture might specify how is put together at a very high level.  For example, software architecture might specify that we use a three tiered approach or an n-tiered approach.  This approach places our view code is at one level, our business rules are at another level, and our data access at yet a third level.

Continue reading “Software Architecture without Test Driven Development is DANGEROUS!”

NUnit, Unity Dependency Injection, MOQ and Private Fields

loading…

I had an interesting puzzle to solve this week that I thought I would share with you in case someone else is looking for a similar solution.

There was some code that I needed to test that ultimately called into the database. Since this is a UNIT test and all I was interested in testing was one specific function and the state of one specific field in another  object, I had neither the need, nor the desire, to let that call to the database happen.  Since MOQ is  my mocking framework of choice, I wanted to mock out the database object the method was using so that it would return whatever was expected without actually calling down into the database.

There were several problems.  The first was that the database object is a private field in the class I was testing and it got created by the constructor.  Second, the code that needed to use the database object is passing the object by reference (using the “ref” keyword) so that I could no setup my class that needed that object to just ignore it.

There were some other items I needed to inject, but they were pretty straight forward.

Disclaimer

But first, I realize that some purist out there is going to leave me a comment that says you shouldn’t use a Dependency Injection container in your unit test.  My answer to that is, yes, ideally, one should not do this.  But, not everything is ideal.  Not every project is a “green field” project (and in fact about 95% of them aren’t).  And in some cases there is so much technical debt involved that the best we can do is a hack.  Read, Working Effectively with Legacy Code for other illustrations of “hacks” to get code under test.

So, there’s the problem.  It may not make a lot of sense yet, especially if you are not familiar with the tools.  So let’s walk through some code.

The Code

The main method I wanted to test was hanging off a POCO class.  It is using what we call a “visitor” pattern (though I’m pretty sure this is not what the pattern is supposed to look like).  So we have an Accept() method hanging off of it that knows how to store the poco into the database.

That method has a method it calls that hangs off a crud object called Create() that takes the POCO and a reference to the database.

I want to mock the Create() method so that it never actually gets called.  The method should return the POCO as part of a list of the POCO’s type.

Mocking out the crud object is pretty straight forward:

_mockCrud = new Mock<ICrud>()

 

and then registering it with the Unity DI container:

container.RegisterInstance(_mockCrud);

The real issue, and the main point of this post, is that when I wanted to call Create() what I needed to do was:

_mockCrud.Setup(
    x => x.Create(It.IsAny<IPOCOType>(), 
        ref It.IsAny<IDatabaseType>())
    .Returns(pocoList);

Which you can’t do.

What you have to do instead is:

_mockCrud.Setup(
    x => x.Create(It.IsAny<IPOCOType>(),
        ref _database))
    .Returns(pocoList);

And the only way this will work is if the _database variable is pointing to the same object that will ultimately get called.

So, here is the magic that I used to make all that work.

Reflection.

The database object I needed was created as part of the constructor in yet another object that I pass into the Accept() method.  So, I create that object and then use reflection to get the instance of the database from it.

var visitor = new DataVisitor();
var fieldInfo = visitor.GetType()
    .GetField("_database",
        BindingFlags.NonPublic | BindingFlags.Instance);
if(fieldInfo != null)
{
    _database = (Database)fieldInfo.GetValue(visitor);
}

And now I can use the Setup code I’ve already specified.

Hope that helps someone else.

Automated Web Application Functional Testing

WebTestingCloud

One problem we often have when performing application test is that if we are testing  applications that modify the database in some way, we can’t test without modifying the database.

In an ideal world, one way you could deal with this issue is to create a test database that has known data.  But even then, you have to go through the effort of setting up the data prior to each test.

Continue reading “Automated Web Application Functional Testing”