Skip to content

Conversation

@mwhelan
Copy link
Member

@mwhelan mwhelan commented Jan 25, 2015

Sometimes it is convenient to prevent methods that have ExecutableAttributes from showing on the reports.

@JakeGinnivan
Copy link
Member

If adding to other ways should we look at reopening #186. I think it would be handy

@JakeGinnivan
Copy link
Member

But as Mehdi says, if a non-executable step fails the report will look weird.

Do we need to deal with that case?

@mwhelan
Copy link
Member Author

mwhelan commented Jan 25, 2015

Yes, I think it's a valid concern. It would be good to show the error on the report, even though the method is not reported.

@mwhelan
Copy link
Member Author

mwhelan commented Jan 25, 2015

And yes, I do think we should reopen that. We should be consistent across APIs.

JakeGinnivan added a commit that referenced this pull request Jan 25, 2015
Added ShouldReport to ExecutableAttribute
@JakeGinnivan JakeGinnivan merged commit ce426c8 into TestStack:master Jan 25, 2015
@JakeGinnivan
Copy link
Member

Reopened #186

@MehdiK
Copy link
Member

MehdiK commented Jan 25, 2015

The hidden steps make me feel uncomfortable because I don't know how to deal with a failing step in the reports. We need to think about how to deal with them? Perhaps when a hidden step fails, we still report it in the html report!!

@mwhelan
Copy link
Member Author

mwhelan commented Jan 26, 2015

Yes, I think we should report it in the HTML report.

@JakeGinnivan
Copy link
Member

I think so as well. If we fail a hidden step, add them.

But the things I use it for would never fail. An example is a mocked service with a set behaviour of returning an observable data stream.

interface IService
{
   IObservable<Data> GetData();
}

By default it does

Observable.Return(...);

But in my hidden step I do:

service.GetData.Returns(dataSubject);

Now my test can have steps which check the form is loading when it should be (because data is no longer returned automatically) and control exactly what happens when data does load.

@MehdiK
Copy link
Member

MehdiK commented Jan 26, 2015

The problem is that once that feature is in, we don't know how others are
going to use it; so need to cater for the worst possible usage.
On 26/01/2015 5:22 PM, "Jake Ginnivan" [email protected] wrote:

I think so as well. If we fail a hidden step, add them.

But the things I use it for would never fail. An example is a mocked
service with a set behaviour of returning an observable data stream.

interface IService
{
IObservable GetData();
}

By default it does

Observable.Return(...);

But in my hidden step I do:

service.GetData.Returns(dataSubject);

Now my test can have steps which check the form is loading when it should
be (because data is no longer returned automatically) and control exactly
what happens when data does load.


Reply to this email directly or view it on GitHub
#193 (comment)
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants