1

The question is whether it is bad practice to have a method in your Application project that has no other purpose than to generate data for your test project.

I have a unit test that I am using to do a cursory exam to ensure that all valid inputs will run through the primary method of my application without any errors at all. I essentially run a method to pull every valid input out of the database and then run each of those through the primary method of the application. If it fails, a bool is set to false.

The sample of the code I am using to do this is below. The question is whether there is a better way to do this that won't require me to add anything to the Application code. The below method requires me to have a method(TestMethod) in the Application project that pulls all valid parameters in order to run them through the primary method(CheckAvailability) in the test project.

public void SomeUnitTest()
{
    Availability Availability = new Availability();

    List<TestParam> paramList = new List<TestParam>();
    bool success = true;
    bool expected = true;

    //This method pulls every valid param from my database.
    paramList = Availability.TestMethod();

    //This foreach loop runs each one of those valid params through another method. If there is an error, 
    //success is set to false otherwise it remains true.
    foreach (TestParam s in paramList)
    {
        try
        {
            InputWrapper Wrapper = new InputWrapper();
            Wrapper.ApplicationName = s.APPname;
            Wrapper.Location = s.APPLocation;
            Availability.CheckAvailability(Wrapper);  
        }         
        catch(Exception)
        {
            success = false;
        }

        //I then assert that success remains true. If it is false, it means that
        //the method failed.
        Assert.AreEqual(expected, success);    
    }
}
Xaruth
  • 3,968
  • 3
  • 17
  • 24
TimidObserver
  • 147
  • 2
  • 11

2 Answers2

3

You seem to be under the impression that a datasource for tests is a questionable thing.

Let me start off by saying that this is not the case at all, but, (there's always a but) you should keep in mind that a good unit test is very easily written (and - maybe more importantly - read) so ideally you should have as few layers in your unit tests as possible.

This brings you to a predicament: do I make sure that anyone who reads my test can just look at the test method and knows everything that will be put in motion, or do I add some layers to keep the tests clean but also add complexity?

As is the case with many things: you will have to compromise. I would argue that you could go up to 2 or 3 layers of complexity in your unit tests, but it definitely shouldn't be more than that.

In your example this would mean that we can add a layer of complexity by extracting our testing data to keep it separated from the actual tests.
This will not be that big of a burden on understand the test but it will make it clear to write and maintain them.

Another aspect of your question that raised a few eyebrows: you're talking about having the test data in a database.

This is not your production database, is it? If it is: stop testing against live data. You need absolute control over your tests to ensure that no test data is changed and that the environment doesn't change without you knowing (aside from potential interruptions with the actual production data).

There is no need to use a boolean variable either: a thrown exception will automatically result in a faulty test.

I go into more detail on these things here and here, please read through them and feel free to ask any follow up questions.

Community
  • 1
  • 1
Jeroen Vannevel
  • 41,258
  • 21
  • 92
  • 157
  • Oh god no. I would have a DBA down here already if I was running tests against a production database with live data. I am pretty sure that I don't even have access to the live data. Also, thanks for the link suggestions and detailed answer, I will look through them and try to adjust my test. – TimidObserver Mar 14 '14 at 16:14
1

Personally, I don't believe it is. The purpose of unit testing is to evaluate whether your units of functionality are fit for their purpose. To that end, it's not important where your data is coming from unless that is the responsibility of the method you are trying to test.

That being said, I would lean more towards including a set of sample data in the project to read from, since it allows you to modify the test data you're using more readily.

iamthe0ne23
  • 11
  • 2