Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Screenshot doesn't always capture error / failure details #1361

Closed
andreiashu opened this issue Feb 22, 2018 · 5 comments
Closed

Screenshot doesn't always capture error / failure details #1361

andreiashu opened this issue Feb 22, 2018 · 5 comments

Comments

@andreiashu
Copy link

andreiashu commented Feb 22, 2018

Current behavior:

We are using Cypress for testing an API E2E. The screenshots will explain better for me but basically when the test fails the screenshot does not wait long enough in order for the cypress UI to update the DOM with the error details.

Desired behavior:

Screenshots should contain error details

How to reproduce:

I just run the following test with cypress run basically:

describe('demo a failing test', () => {
  it('will fail!', function() {
    expect({"foo": "bar"}).to.deep.equal("foo": "baz");
  })
});

Additional Info (images, stack traces, etc)

Current:
current

How it appears when the next test fails:
how it appears when the next test fails

  • Operating System: OSx and Linux
  • Cypress Version: 2.0.2
  • Browser Version: Canary 66
@jennifer-shehane jennifer-shehane added type: bug stage: ready for work The issue is reproducible and in scope labels Feb 22, 2018
@brian-mann
Copy link
Member

This is a known issue for awhile. It has to do with React (which is what we built the reporter in).

The problem is that taking a screenshot is an async process. But React also renders async. To date - we acutally do synchronize taking a screenshot with React - but its in a shallow component and there is a chance the nested components have not rendered yet.

The solution seems simple - wait until all the the UI parts have rendered right?

The problem with that is that the longer we wait to take the screenshot the less accurate it will be when the state of your app fails. We're talking about milliseconds here - but those matter.

The question is - would you rather have an accurate screenshot of the way your app looked when it failed? Or would you rather have a screenshot including the error in our reporter? It's unfortunately not possible to have both.

@brian-mann
Copy link
Member

The other thing worth mentioning here - is that this is why we capture both the error + stack, the screenshot, and the video in our dashboard.

It's not enough to have just 1 of them - you need more context to really understand what's going on.

@chrisbreiding
Copy link
Contributor

We're working on reproducing this and having trouble. From your screenshot, it looks like there are more tests than in your example code. Could you post all the code you used to reproduce this?

@jennifer-shehane jennifer-shehane added stage: needs information Not enough info to reproduce the issue and removed stage: ready for work The issue is reproducible and in scope labels Apr 20, 2018
@jennifer-shehane
Copy link
Member

Hey, I know this does occur as I have seen it myself. We'll need a reproducible example to track down the exact issue though. Can anyone provide?

@jennifer-shehane jennifer-shehane changed the title Screenshot functionality does not always capture error details Screenshot functionality does not always capture error / failure details Feb 11, 2019
@jennifer-shehane jennifer-shehane changed the title Screenshot functionality does not always capture error / failure details Screenshot doesn't always capture error / failure details Feb 11, 2019
@jennifer-shehane
Copy link
Member

Unfortunately we have to close this issue as there is not enough information to reproduce the problem.

Please comment in this issue with a reproducible example and we will reopen the issue. 🙏

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

No branches or pull requests

4 participants