Reddy
Reddy

Reputation: 501

Rhino Mocks: How to Mock a Database call in a Parameterless Method?

I am writing unit tests for an ASP.NET MVC application in C# using NUnit and Rhino Mocks. I am having some trouble testing this method:

public void Install()
    {
        Database.SetInitializer<DraftOrderObjectContext>(null);
        var dbScript = CreateDatabaseInstallationScript();

        Database.ExecuteSqlCommand(dbScript);
        SaveChanges();
    }

Just to clarify, Database is not referring to a local object. The first one "Database.SetInitializer..." refers to:

System.Data.Entity.Database

and the second "Database.ExecuteSqlCommand..." refers to:

System.Data.Entity.DbContext.Database

Since the method does not return anything, I figured it would be sufficient to make a mock and verify that Database.ExecuteSqlCommand(dbScript); was called at least once.

Now I've done this before, but that involved passing a database context to the method, which is easy enough to mock, however, in this case there are no parameters. I need to somehow find a way to mock 'Database'.


I have tried straight up assigning a mock like so:

System.Data.Entity.DbContext.Database = MockRepository.GenerateMock<System.Data.Entity.DbContext.Database>();

but that breaks syntax because the property is read only.


I have also tried mocking DbContext like so:

System.Data.Entity.DbContext instance = MockRepository.GenerateMock<System.Data.Entity.DbContext>();

        instance.Expect(someCaller => someCaller.Database.ExecuteSqlCommand("sql"))
            .IgnoreArguments()
            .Return(1)
            .Repeat.Times(1);

but I get a runtime error saying DbContext.getHashCode() must return a value. I then tried stubbing the getHashCode method to make it return something but that had no effect.


I am still fairly new to mocking so I may be missing some fundamental concept here. My apologies if that is the case. Any help is much appreciated!

Upvotes: 0

Views: 1298

Answers (1)

tonicsoft
tonicsoft

Reputation: 1808

I'm afraid the only answer worth giving here is that the code must be modified to be more test-friendly. Trying to write unit tests for methods that make calls to static classes, properties or methods is not a rewarding or worthwhile task. You suggest that you may be missing a fundamental concept here and this may be it: static is unit testing's worst enemy and the collective wisdom is that there isn't much point putting a lot of effort into testing things that use static resources. Just refactor the code.

If refactoring the code is truly impossible then why would you need to unit test it (this is not a rhetorical question, please comment)? If the concern is that you need to mock these objects as part of other tests, then you should wrap the evil, unmodifiable code with a test friendly interface and mock that instead.

Upvotes: 1

Related Questions