单元测试无效方法

Question

I understand that you can unit test a void method by checking for its effects. However, looking at the loadConfigFile method in this code:

    internal XmlDocument configData;

    public ConfigFile()
    {
        configData = new XmlDocument();
    }

    /// <summary>
    /// Load config file into memory
    /// </summary>
    /// <param name="filename">path and filename of config file</param>
    public void loadConfigFile(string filename) 
    {
        if(string.IsNullOrEmpty(filename))
            throw new System.ArgumentException("You must specify a filename");

        try 
        {
            configData.Load(filename);
        }
        catch(Exception ex)
        {
            throw new Exception("Config file could not be loaded",ex);
        }
    }

It loads a config file into a private field - which needs to be kept private so that developers do not modify the value directly. Instead the modification will be done through setConfigValue and getConfigValue methods (which I would assume need to be tested separately).

Given this, how would I test that the loadConfigFile actually worked? As I cant access the private configData field.

Answer 1

Where else in that class is configData used?

If, say, you have a method like

public string GetValue()
{
    return configData.GetsomeDataFromThis;
}

Then I suggest you have a test like so:

public void ReadValueFromLoadedConfigData()
{
    // Arrange.
    const string ExpectedValue = "Whatever";

    var sut = new ConfigFile();

    sut.loadConfigFile(@"C:\PathToTheConfigFile");

    // Act.
    string actual = sut.GetConfigValue();

    // Assert.
    Assert.AreEqual(ExpectedValue, actual);
}

In your tests, try to test only the public interactions, since going deep into the class, by having to read values of private fields, means your class isn't test friendly.

Answer 2

You could test that getConfigValue returned the values loaded from the file, basically.

Just because you test setConfigValue / getConfigValue in other tests doesn't mean that you can't use them in the test for loadConfigFile .

As an aside, I'd strongly urge you to follow .NET naming conventions, starting your method names with capital letters. (I'd also urge you to make your field private rather than internal...)

Answer 3

A unit test is basically a way to say "given this input, verify that this happened", it is not a substitute for verifying that your application is in a valid state.

In the example, the loadConfigFile method throws an exception if the precondition is not met, or the load operation failed. This will then be detected in the unit test, which will fail.

If any other validation is needed on the config beyond that no exception is thrown, that should be handled in the class itself.