1
\$\begingroup\$

Take the below code:

public interface ISettingsManager
{
    SettingData GetSettingByIdentifierOrCreateIfDoesNotExist(Enum identifier);
    T GetSetting<T>(Enum identifier);

}

[IocComponent]
public class SettingsManager : ISettingsManager
{
    private readonly ISettingGetItemByIdentifierService _settingGetItemByIdentifierService;

    public SettingsManager(
        ISettingGetItemByIdentifierService settingGetItemByIdentifierService)
    {
        _settingGetItemByIdentifierService = settingGetItemByIdentifierService;
    }

    public SettingData GetSettingByIdentifierOrCreateIfDoesNotExist(Enum identifier)
    {
        SettingData setting = //GetSetting from database;
        return setting;
    }

    #region ISettingsManager Members


    public T GetSetting<T>(Enum identifier)
    {
        var setting = GetSettingByIdentifierOrCreateIfDoesNotExist(identifier);
        return (T)setting.Value;
    }

    #endregion
}

The ISettingsManager is created to retrieve settings for an application. The main logic is done in GetSettingByIdentifierOrCreateIfDoesNotExist. The logic is not shown in the example, but this should try to get the setting from the database.

The method GetSetting is a convenience method which basically retrieves the setting from the other method, and casts it to the required value as setting.Value is of type object.

I am trying to follow the Test-Driven-Development guidelines, and hence I assume a unit-test should be created for this method as well. As it is, one cannot just mock the GetSettingByIdentifierOrCreateIfDoesNotExist, as it is in the same class.

Does it make sense to split this out in another class, so one can mock it? Personally, I think that these two go together. Any ideas how one would approach this would be greatly appreciated :)

\$\endgroup\$
2
  • 2
    \$\begingroup\$ If you're following TDD, you should have written the tests before the actual code :) \$\endgroup\$
    – walther
    Apr 10 '13 at 12:43
  • \$\begingroup\$ I did create the tests, and they're not posted here :) I'm just thinking that it might be a bit of an over-kill, creating unit-tests for such simple methods, when it is just a 'convenience method'. \$\endgroup\$ Apr 10 '13 at 17:10
2
\$\begingroup\$

I'm not sure if you need GetSettingByIdentifierOrCreateIfDoesNotExist declaration in your interface... Do you have special use cases where GetSetting<T> is not enough?

If I'm right and all you need is just GetSetting<T> method then you can go ahead and make GetSettingByIdentifierOrCreateIfDoesNotExist method private, thus you'll make it an implementation specific that doesn't need to be tested separately, you'll test it by testing GetSetting<T>.

If you do need GetSettingByIdentifierOrCreateIfDoesNotExist method, then I would go with a different approach: since GetSetting<T> is just an additional feature on top of GetSettingByIdentifierOrCreateIfDoesNotExist, you can remove it from ISettingsManager interface and rewrite as an extension method like this:

public interface ISettingsManager
{
    SettingData GetSettingByIdentifierOrCreateIfDoesNotExist(Enum identifier);
}

public static class SettingsManagerExtensions
{
    public static T GetSetting<T>(this ISettingsManager manager, Enum identifier)
    {
        var setting = manager.GetSettingByIdentifierOrCreateIfDoesNotExist(identifier);
        return (T)setting.Value;
    }
}
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.