0

I'm trying to familiarize myself with unit testing. I've written a small application that parses data from the Internet and stores it into a db. For this I'm using Entity Framework.

Since many of the methods are void methods such as

public void UpdateSiteValue(Site site, ObjectContext context)

This method could be used for updating some value in the db. So I'm basically wondering how to approach this from a unit testing perspective. Maybe I could mock the object context?

Would appreciate any input.

johan
  • 6,578
  • 6
  • 46
  • 68
  • Testing whether data has been persisted to the database is an integration test, rather than a unit test. –  Sep 05 '12 at 15:07

1 Answers1

2

It depends on what you're testing for.

Since you're returning void, you can't test the return of the function - so are you wanting to test that your method will actually make the changes in the database? If so, then mocking your context isn't the best solution, because you aren't testing the actual code. Ladislav Mrnka made a great post about that. Could you wrap your test in a transaction scope and then do a rollback afterwards? The Id's would get incremented, but at least you'd be testing everything.

Alternatively, if you're wanting to test that your method is doing everything right - up until you get to the database layer there's a few ways to go about that. Something that is suggested alot is to use the repository pattern, so that you don't have a dependancy on EF in your test. Truewill made a good post about this also. He also links to an MSDN article about this, using an in memory ObjectContext that you may find relevant.

Here is some more general reading about unit vs function vs integration testing that can help.

Community
  • 1
  • 1
Mark Oreta
  • 10,346
  • 1
  • 33
  • 36