存储有关测试方法的信息的最佳方式

Question

I test some hardware products which have different configuration. I have a test method, which loops over all test cases for all products. Since some products don't support functionalities, some cases should not be tested.

What would be the best way to make the test method more dynamic? I was thinking of using a xml file where I would define, which steps should be executed for which product. Something like:

<products>
<product>
    <id>1</id>
    <steps>
        <step id="1" desc="Description1" />
        <step id="2" desc="Description2" />
        <step id="3" desc="Description3" />
<product>
<product>
    <id>2</id>
    <steps>
        <step id="1" desc="Description1" />
        <step id="3" desc="Description3" />
<product>

Answer 1

Take a look at Moq : you can easily setup some testable scenarios, like:

var mock = new Mock<ILoveThisFramework>();

// WOW! No record/replay weirdness?! :)
mock.Setup(framework => framework.DownloadExists("2.0.0.0"))
    .Returns(true);

// Hand mock.Object as a collaborator and exercise it, 
// like calling methods on it...
ILoveThisFramework lovable = mock.Object;
bool download = lovable.DownloadExists("2.0.0.0");

// Verify that the given method was indeed called with the expected value at most once
mock.Verify(framework => framework.DownloadExists("2.0.0.0"), Times.AtMostOnce());

I also like to use it together with FluentAssertions , for the flexibility of assertions and you can basically read the test, in a (almost) natural language, like:

string actual = "ABCDEFGHI";
actual.Should().StartWith("AB").And.EndWith("HI").And.Contain("EF").And.HaveLength(9);

The examples are from theirs respective home pages.

Answer 2

XML could be ok, but you could use SQLite and a custom configurator or simply a SQLite editor.

Because if you got to configure and make changes on your configuration, as soon as it get bigger and bigger a solution like SQL would allow you to perform changes in your configuration way better.

If you think your configuration schema will vary from time to time maybe you could explore other noSQL options but they're not so portable as SQLite.

I can tell from my experience working in a product which components are configurable with xml files, that as soon as you grow and your xml files got fatter, they start to be a problem. Also updating the configuration in multiple places through regex its not cool. We're now looking forward to migrate to a SQLite like solution.