Re: Dynamically Defining Tests from Config File

Brandon Payton <[email protected]> wrote:

> The purpose of the tests is to establish a baseline of behavior before
> some heavy refactoring.  The component being tested is an ActiveX
> control that takes a number of parameters before loading, and I am
> trying to verify that particular features are enabled/disabled based
> on those parameters.  This would then allow me to refactor while
> comparing behavior to the original design.  Ideally, this would have
> little if anything to do with the UI, but that's why it should be
> refactored.
>
> Would this be considered "acceptance testing", and if so, what would
> you consider "developer testing"?

Well, my personal pigeonholing of this would depend on a couple of
things.  Is the number of parameters, or the number of combinations of
values for those parameters, very large?  If there're two parameters and
two or three possible values for each of those parameters, I might put
it into my developer tests and call it a day.  If there are ten
parameters, and the possible combinations are large, then I might

I personally would put this into the integration testing category, not
because of *what* is being tested, but because the seeming best way to
test it would be to set up a table of inputs, and check the outputs.  If
the number or values of inputs and outputs needs to change with any 
frequency, then I'd attempt to write something the end user could 
interface with and change if he or she needed to.

For my purposes, "acceptance" testing is the tests I would write to 
which the user can supply inputs and check the outputs themselves, for 
example using FitNesse or some other method with a customer facing 
component.  This doesn't necessarily imply automation, though that would 
certainly be a benefit.  Unfortunately, I haven't been able to do much 
of this, because my "customers" don't have the desire to do that; they'd 
much rather foist that off on the official QA people.

"Developer" testing is the tests I write based on my understanding of 
what the tested component is supposed to do, e.g. when supplied with a 
string, it should return that string reversed.  This is the kind I've 
been doing, though in an isolated "what's he doing over there in that 
corner of his" type of way.

Something like this came up on the TDD list this afternoon, and one of 
the posters described something that xUnit.net supports that looked 
really interesting.

public class MyFixture {
    public static DataTable MyDataProp {
        get {
            DataTable result = new DataTable();
            result.Columns.Add(null, typeof(string));

            result.Rows.Add("File1.xml");
            result.Rows.Add("File2.xml");   // etc.

            return result;
        }
    }

    [Theory, DataViaProperty("MyDataProp")]
    public void FileExists(string filename) {
    }
}

Brad 


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4