5

I am using 3 tier architecture: Controller, Business, and Data Layer. In my Data Layer, I am making a call to an Sql Server Database by passing Connection String and other necessary parameters.

I have to write unit tests for the Controller layer and Business layer. I want to write a stub (fake repository) from which I would return the hard coded values/result. When I write a test for business layer, the logic should call this stub instead of the real database.

How can I write the code in the business layer to achieve this?

Business Layer:

public string GetValues(string xmlData)
{
    DataObject do = new DataObject ();
    string result = do.GetValues(xmlData);
    return result;
}

Data access:

public static string GetValues(string xmlData)
{
    return SqlHelper.ExecuteScalar(
        ConfigurationManager.AppSettings["ConnectionString"].ToString(),     
        "DBO.usp_GetDetail",
        xmlData
    ).ToString();
}
ryanyuyu
  • 6,366
  • 10
  • 48
  • 53
palak mehta
  • 696
  • 4
  • 13
  • 30

1 Answers1

2

In order to test you scenario, your code has to be testable. If it follows SOLID principles it most likely is. But let's focus on what is essential to do this kind of unit testing:

  1. Your business layer should depend on abstraction (this in most of the time means interfaces) instead of concrete classes. This way, in unit test you can provide stubs for those dependencies.
  2. Business layer's dependencies should be provided via dependency injection (for example constructor injection), so that in unit tests you can easily pass them stubbed objects.

Same principles should apply to Controller - Business Layer interaction. When you stick to those two rules (which essentially narrows to SOLID's dependency inversion principle), your code will be much more unit testable than otherwise (sticking to SOLID principles is overall good idea).

Since you'll probably end up writing mocks/stubs, I suggest using existing mocking framework, like Moq or FakeItEasy.

Edit - if code is that tighly coupled, your options are limited to:

  • refactoring (this is obvious, but with legacy system might not be possible/worth the effort)
  • use paid tool, like TypeMock Isolator. Isolator uses compiler API to intercept method calls and as a result can stub/mock calls to static methods, private members and all the stuff that free frameworks don't let you.
  • use Microsoft Moles. Moles generate fake types utilizing dynamic assembly generation. This gives you Isolator-like flexibility, but is free. Note that it's a bit heavier framework (extra assembiles, files etc).
k.m
  • 30,794
  • 10
  • 62
  • 86
  • Thanks Jimmy , The problem with the existing code is , it's tightly coupled. Coding is done using concrete class and not interface. – palak mehta May 17 '12 at 08:44
  • @palakmehta: I see. This complicates testing, but doesn't make it impossible. You'll probably need to utilize different tools. See my edit. – k.m May 17 '12 at 09:48
  • @k.m So in retro, what did you end up doing? Did you end up using a tool like TypeMock or you used the Sprout method to refactor the code base? – Vin Shahrdar Nov 08 '18 at 14:40