Create tags for scenarios

[MehdiK]

We've been capturing and setting Story.Category for a long time now without using it. We could definitely use it in file reporters to group related stories.

Thoughts?

[JakeGinnivan]

I like it, I think it would be handy

[mwhelan]

Agreed

[JakeGinnivan]

I have been thinking about this.

We should change this to traits like xUnit uses, that way I can assign multiple traits to a story. For example, the Story/Stories (in TFS/GitHub/Jira) that are associated with this story, and any other metadata.

The reason for this is that we would like to also define manual tests in BDDfy, tag them as manual and make them inconclusive. Testers/QA's can then filter the HTML report (yes, I think we need to add filtering/grouping based on traits), grouped by story to do their test runs.

It also gives better tracability for the stories, and would encourage changing existing stories rather than putting the JIra/Tfs id into the story name like I often see.

What do you guys recon?

[MehdiK]

I think having multiple categories on a story is a good idea. I would also like to rename it tags.

I just realized the current implementation is completely broken. Category is defined on Story as string but is provided and set in BDDfy extension method which you BDDfy a scenario and basically each call overrides the last one!! If we want to keep it on story then I think it should be provided as a story metadata (via StoryMetadataProvider; e.g. StoryAttribute etc). From there we can allow for multiple categories/tags.

I think filtering by categories is a good idea too; but we could put this out after v4 as it's not a breaking change but a lovely feature.

[JakeGinnivan]

Replacing categories with tags is breaking though, so lets get that in :)

[MehdiK]

BREAK ALL THE THINGS!! ;)

[mwhelan]

So, do we want tags on Story, Scenario, or both? If they are to be like traits (which I think they should) then they should be on Scenario, which is analogous to a test. What do you think of having them on both?

[JakeGinnivan]

Yeah, I am thinking scenario

[MehdiK]

Yeah, I think they make more sense on scenarios. We could keep it as an argument on BDDfy; but I personally think that's ugly particularly now that we want to have multiple of them.

Here is a half-baked idea for the API (mostly based on examples for API consistency and also ease of use):

this.WithTags("cart", "sprint-2").BDDfy();

public class Tags
{
    public string[] Tags { get; private set; }
    public object TestObject { get; private set; }

    public static Tags WithTags(this object testObject, params string[] tags)
    {
    }
}

I am also thinking we should create BDDfy extensions for Example (and Tags) classes so we don't have to keep examining the object testObject on each level figuring out what the testObject actually is.

[mwhelan]

Yeah, both ideas sound good to me.

[JakeGinnivan]

.WithExamples().WithTags will be awful to deal with as then you have Tags(Examples(FluentScanner(realTestObject))) all wrapped up.

Tags + examples should maybe live off the fluent scanner? I don't quite understand the suggestion @MehdiK is making, but anything which stops the wrapping is a good idea

[MehdiK]

Good catch @JakeGinnivan.

My suggestion was to have a several overloads of BDDfy extension method, running on Example (and potentially Tags) instead of object. It won't prevent wrapping but at least when you're deep in you know what you're dealing with without having to check the type every time.

[JakeGinnivan]

Won't it make WithExamples and tags unable to work with each other?

[MehdiK]

WithExamples works with object and I think it should continue to do so, or we could add an optional param to it getting the FluentScanner and enforce the TestObject to actually be the TestObject! But you're right: this could result into an API explosion where we need to cater for all combinations!