单元测试业务逻辑层

Question

I'm starting to introduce Formal Unit Testing in our company as we are having a project that's becoming bigger and bigger and on this project another guy is going to help me. So I need to be sure that what he does doesn't break up all and vice-versa.

I'd like to introduce a CI server too, but this will be the topic of other questions. Now the question is: I'm currently reading "The Art Of Unit Testing" (that's a suggested masterpiece!) and what the author underlines is that Unit Testing is different from Integration Testing. That's clear for me and, if I understood well, Business Logic unit testing should avoid to be dependent on database connections and so on. First of all: am I right?

So, supposing that I'm right (ie when I unit test my BLL I should stub the database), how will I do it? I've read that there are some framework for db mocking. Should I use one of these? Which do you use?

Next question: do you really think this is a correct way to do? I mean: in my project the BL interfaces with database through Entity Framework. So, for example, when the method "UpdateItem" in my BLL is called, it does something and then saves the ObjectContext. This ObjectContext is the Entity Framework dependency I need to remove in my BL. But what should I test in such a method? I really can't understand unit testing the BL layer without testing the DAL together... Can you give me some example?

Thanks a lot for your efforts!

Marco

Answer 1

Yes,

Business Logic unit testing should avoid to be dependent on database

You are right about that.

I recommend that you:

• use a suite of unit tests for the Business Layer, using stubs instead of real DB calls. You can stub the DB with whatever suits you best (you own fake classes or mocking libraries), provided that you have abstractions over the DB components.
• use a suite of Integration tests to test the actual DB calls (and only that!)

The main differences between unit tests and integration tests are: * unit tests are fast and don't need any configuration * integration tests may be slow and require proper configuration (a database should be set up and there should be a proper connection string pointing to it).

I think this is good because it allows you to run the business unit tests very often as you make changes to your code. This is important, because you get very fast feedback (usually within 1-2 seconds) that the changes you made didn't break anything.

Once in a while, you can run the integration tests (that will take longer) to validate that the DB still works correctly.

Also, I suggest you read the book that you mentioned. It think it is a very important source of information on this topic.

Answer 2

Stubbing the database is a huge task, that I don't think is worth it. I prefer having a special database copy, with carefully prepared data that is suitable the unit tests.

The tests can be run within a transaction that is rolled back at the end of the test. That way, the unit test database is never modified by the tests and always kept in a known state.

I wrote about it in Using Transactions for Unit Tests on my blog. The sample code there is for linq-to-sql, but the same approach works for entity framework as well.