-
|
I have a usecase where I have created a bunch of end to end test. I want to establish that my application supports different protocols and want to run the end to end test on the protocols. This can be done simply: public sealed class ApplicationFixtureGeneratorAttribute<T> : DataSourceGeneratorAttribute<ApplicationFixture<T>>
where T : notnull
{
protected override IEnumerable<Func<ApplicationFixture<T>>> GenerateDataSources(DataGeneratorMetadata dataGeneratorMetadata)
{
//Is it possible to prepend all tests with the name of the protocol - sort of as a category
foreach (var protocol in Enum.GetValues(typeof(WebProtocol)).Cast<WebProtocol>())
{
var serviceMatches = FindMatchingServices();
foreach (var func in ApplicationFixtureIterator(serviceMatches, protocol))
{
yield return func;
}
}
}
}Is it possible to prepend the current tests' name with a category here? I am very very interested in the possibilities TUnit unlocks in terms of generating my own tests in a programmatic manner. It is something I have really been missing in XUnit. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
A TestContext doesn't exist before generators are run, because the data generated will create new tests. So you'd have to go for a two phased approach. The ObjectBag in the test builder context gets passed to the test context when eventually built. Something like this in your data generator before you yield: dataGeneratorMetadata.TestBuilderContext.Current.ObjectBag["MyDisplayNamePrefix", "Category");And then a custom attribute on the test like (pseudo-code): public class CustomDisplayNamePrefixAttribute : Attribute, ITestRegisteredEventReceiver
{
OnRegistered(TestContext context)
{
context.SetDisplayName(context.ObjectBag["MyDisplayNamePrefix"] + ": " + context.GetDisplayName())
}
} |
Beta Was this translation helpful? Give feedback.
A TestContext doesn't exist before generators are run, because the data generated will create new tests. So you'd have to go for a two phased approach.
The ObjectBag in the test builder context gets passed to the test context when eventually built.
Something like this in your data generator before you yield:
And then a custom attribute on the test like (pseudo-code):