views:

34

answers:

1

Hi Guys

I have the following code that was written without Tests but is actually quite well designed and loosly coupled. The CachedBindingListView constructs a number of objects namely the page provider and the Cache. As Follows.

    /// <summary>
    /// Inner data cache
    /// </summary>
    private Cache<T> InnerCache { get; set; }

    /// <summary>
    /// Page provider
    /// </summary>
    private PageProvider<T> PageProvider { get; set; }

    /// <summary>
    /// the Request object that is built with a filter, sort, no of pages etc.
    /// </summary>
    private BindingListRequest<T> BindingListRequest { get; set; }

    #endregion

    #region Constructor

    /// <summary>
    /// New object
    /// </summary>
    /// <param name="bindingListRequest">Request for a particular set of Business Objects</param>
    public CachedBindingListView(BindingListRequest<T> bindingListRequest)
    {
        BindingListRequest = bindingListRequest;
        PageProvider = new PageProvider<T>(BindingListRequest);
        InnerCache = new Cache<T>(PageProvider);
    }

I have written tests for the BindingListRequest, PageProvider and InnerCache. but now want to start writing Tests for the CachedBindingList. The constructor currently takes a BindingListRequest and constructs a page provider and inner cache based on this.

For test purposes I want to be able to provide at TestDouble for PageProvider and Cache.

What are the best ways of doing this. I have considered the following options.

1) Add the PageProvider and InnerCache to the Constructor and inject the appropriate type in when required.

2) Use A DI framework to Resolve the PageProvider and Cache within the CachedBindingListView constructor. This would involve either injecting the DI container into the CachedBindingListView constructor or making it global.

3) Creating a factory that creates PageProvider and Cache and possibly even the CachedBindingListView and using this factory to create the PageProvider and InnerCache in the CachedBingingListView's constructor. This would again involve either making the factory global or injecting it into the CachedBingingListView's Constructor.

4) Making the PageProvider and InnerCache Properties Public and use a DI framework to create the CachedBindingListView and inject the PageProvider and InnerCache properties via property injection. Thus allowing me to override the Cache and PageProvider being injected during testing.

I can see how any of these can work but all of them seem a bit unwieldly and forced. What are the opinions out there. What advice does anyone have on the best way of doing this.

thanks GD

A: 

If you just want to be able to test it - one option is to make a protected constructor with all three properties injected. Then in your test make a FakeCachedBindingListView that inherits from the CachedBindingListView and inject the needed stubs, mocks (pick your poison).

That's the one I'd go with, anyway.

Goblin
Hi Goblin thanks for the anser should have listed this as one of my options.This also feels a bit like I am modifying my production code just for the purposes of testing but is definitely a good option.
That is true - but you are bound to change you production code anyways - be it DI / IoC. And it is a small change that will have no impact on the functionality of the production code. Good part is that if you do it this way, you can later introduce DI by making the new constructor public.
Goblin
This is true. I have changed the class as you suggested and started writing tests for it and it is workin pretty good.tks