Added ReportModel for reports

[mwhelan]

Discussed this with Mehdi. Was persisting BDDfy reports to Raven and there were issues with serializing/deserializing the domain objects used in the reports. This PR maps the domain objects to a ReportModel of POCOs just for reports.

[JakeGinnivan]

Was there an issue with the 2.0 runner?

[mwhelan]

No, should I put it back to xunit 2.0?

[JakeGinnivan]

If we are introducing a reporting model, it would be good to raise the Examples property up a level so it's on the Story not the scenario.

That would remove the need for story.Scenarios.First().Example?

[JakeGinnivan]

@MehdiK thoughts on the PR. I don't know the reporting stuff that well?

@mwhelan it would be good to separate the fix for #212 out of this PR so they can be reviewed/merged separately.

To work some git magic and sort all this out:

git checkout -b ReportingModel   # Lets move the reporting model stuff to it's own feature branch
git checkout master
git fetch upstream                        # assuming you have two remotes, origin which is your fork and upstream which is the main repo
git reset --hard upstream/master # make master look like the main repo
git checkout -b ReflectiveAndFix
git cherry-pick  a131abd              # Grab your fix for 212
# merge anything which comes up with `git mergetool`
git push origin ReflectiveAndFix
git checkout ReportingModel
git reset HEAD~1 --hard              # get rid of the 212 fix
git rebse upstream/master          # rebase onto the new master
git push origin ReportingModel

Then close this PR and open two more from the two different branches :)

I can do this for you btw, but just incase you want to learn some gitfoo.

[mwhelan]

Thanks @JakeGinnivan . Yeah, if you could do it that would be awesome. My head is full of Service Fabric today and no room for gitfoo! :)

[MehdiK]

To avoid confusion, do you think it's worth calling these StoryModel, ScenarioModel etc?

[MehdiK]

Thanks for the PR @mwhelan.

I am going to sound like a jerk and I apologise. I remember we came to the conclusion that this was a good idea; but I don't remember the reasons. Would you mind refreshing me please? I am just concerned about name reuse confusion as well as the effort required to keep these two models in sync. Is it possible to avoid this change by exposing the bits that should be serialised as public getters?

[mwhelan]

At work we built something to persist reports from each test assembly into RavenDb and then generated an aggregated report from RavenDb. There were issues with serializing the domain objects in RavenDb (it was a few months ago and the exact errors escape me).

When we discussed it at the time, we liked the idea of a simple POCO report model, for the same reasons you would create a view model in MVC. The report model can vary independently of the domain model (such as @JakeGinnivan suggestion above to raise the Examples property up a level to the Story) and it avoids having to make changes to the domain model just to suit reporting needs.

I was originally going to create independent model classes, such as StoryModel/ScenarioModel etc., but during implementation preferred the self-contained report model, for the reasons stated above. I think the name reuse (nested in the report model) actually avoids confusion. I don't see an issue with keeping the models in sync (the tests for the mapping cover that). And the goal is not necessarily to keep them in sync but to allow the report model to vary independently of the domain model. I also think the report model makes it simpler for new users to add a new report as it's much easier to engage with that one class than have to dig through the whole code base.

[MehdiK]

Thanks for explaining @mwhelan. It all make sense now.

[JakeGinnivan]

@mwhelan if you persist this model directly into raven there may be issues deserialising again if we make breaking changes.

[JakeGinnivan]

Rebased and merged manually @ ea6040d