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

pause() should not be ignored with cypress run --headed --no-exit #4044

Closed
Tobbe opened this issue Apr 28, 2019 · 30 comments · Fixed by #18358
Closed

pause() should not be ignored with cypress run --headed --no-exit #4044

Tobbe opened this issue Apr 28, 2019 · 30 comments · Fixed by #18358
Assignees
Labels
good first issue Good for newcomers type: unexpected behavior User expected result, but got another

Comments

@Tobbe
Copy link

Tobbe commented Apr 28, 2019

Current behavior:

cy.pause() is ignored when specs are run with cypress run

image

Notice that I have cy.pause() in the code to the left, but the test on the run hasn't paused

Desired behavior:

I'd want the test to actually pause. Or make it really clear in the documentation that pause() is only working when you use cypress open

This is what it looks like when I use cypress open. I want the same behavior when I run with cypress run

image

Steps to reproduce: (app code and test code)

Add cy.pause() to any test, run it with cypress run, observe that the test is not paused.

Versions

Win 10
Electron (included with cypress)
Cypress 3.2.0

@jennifer-shehane
Copy link
Member

Hey, what is it you are trying to accomplish by adding cy.pause() during cypress run? Are you running with the --headed flag? What is your goal?

But yes, the .pause command does nothing when run during cypress run - code here. https://github.com/cypress-io/cypress/blob/develop/packages/driver/src/cy/commands/debugging.coffee#L43

@jennifer-shehane jennifer-shehane added the stage: needs information Not enough info to reproduce the issue label Apr 29, 2019
@Tobbe
Copy link
Author

Tobbe commented Apr 29, 2019

Yeah, I was running it like this: npx cypress run --spec cypress/integration/mySpec.js --headed --no-exit

I didn't know open existed... So I wasted a bunch of time trying to get pause() working, to debug my test case... 😄

@jennifer-shehane
Copy link
Member

Yeah, this does seem like a valid use case though, I believe the cy.pause() should work as normal when running with --headed --no-exit flags.

@cypress-bot cypress-bot bot added stage: ready for work The issue is reproducible and in scope and removed stage: needs information Not enough info to reproduce the issue labels Apr 29, 2019
@jennifer-shehane jennifer-shehane added type: unexpected behavior User expected result, but got another pkg/driver This is due to an issue in the packages/driver directory labels Apr 29, 2019
@jennifer-shehane jennifer-shehane changed the title pause() is ignored with cypress run pause() should not be ignored with cypress run --headed --no-exit Apr 29, 2019
@JohnnyChiang
Copy link

Because of this issue #1669. I cannot use cypress open to run my case. So I need cy.pause() to work on cypress run

@kuceb
Copy link
Contributor

kuceb commented Oct 8, 2019

@JohnnyChiang can you post in that issue a detailed description of your problem?

@JohnnyChiang
Copy link

@bkucera I ran into the same problem as #1669 (comment) did.
So I have to use cypress run to run my case

@yglin
Copy link

yglin commented Nov 6, 2019

+1, in nrwl/nx environment, "cypress run" is the default command

@DidacHerrera
Copy link

I am in to the same problem, i am running cypress run, need to do this as i run with cli args. Do you know if this is going to be fix soon?

@jdillworth
Copy link

I'm also having this issue. My use case is running cypress for end to end tests with a Vue-based SPA and a Django back end. I want to write my fixture and test setup code in Django (where I already have tooling) and then trigger Cypress tests. I'd like to use pause to experiment and diagnose issues.

@DidacHerrera

This comment has been minimized.

@kuceb
Copy link
Contributor

kuceb commented Dec 2, 2019

@jdillworth Why can't you use cypress open?
@DidacHerrera what do you mean by cli args?
We want to make sure everyone can use cypress open mode.

@jdillworth
Copy link

@bkucera I can now, but I had to make endpoints on my backend to load and reset fixtures. The norm in Django is for the Django CLI to drive the tests.

@kuceb
Copy link
Contributor

kuceb commented Dec 2, 2019

@jdillworth I see, that is a more advanced use case. It would be nice to have a recipe for django (I'm assuming Django rest framework?) so other users have more guidance

@amirrustam
Copy link
Contributor

@jdillworth I obviously don't know how your frontend and backend code is organized, but you can use the cy.exec to call the Django CLI. For example, if you need to load data fixtures you can do:

cy.exec('django-admin loaddata path/to/mydata.json')

@jdillworth
Copy link

@bkucera interesting, it'll probably be a month or so but I'll post something and refer to it here

@jdillworth
Copy link

@amirrustam thanks for the suggestion. In my case I'm generating data sets using parameters and also need to wipe out my app-specific models at times. I think endpoints seems to fit with Cypress' thinking... keep tests as fast as possible, shave off every second. Calling an endpoint is probably faster than calling the command and incurring another python instance's startup time

@amirrustam
Copy link
Contributor

If your data seeding is very context-specific, then specialized endpoints would be more optimal. However, performance is purely dependent on your implementation.

To call you endpoints you can make requests via tasks with cy.task.

@kuceb kuceb added stage: wontfix Cypress does not regard this as an issue or will not implement this feature type: question and removed pkg/driver This is due to an issue in the packages/driver directory stage: ready for work The issue is reproducible and in scope type: unexpected behavior User expected result, but got another labels Dec 6, 2019
@kuceb
Copy link
Contributor

kuceb commented Dec 6, 2019

the code to change this is located here:

https://github.com/cypress-io/cypress/blob/decaf-firefox/packages/driver/src/cy/commands/debugging.coffee#L43

 Commands.addAll({ type: "utility", prevSubject: "optional" }, {
    ## pause should indefinitely pause until the user
    ## presses a key or clicks in the UI to continue
    pause: (subject, options = {}) ->
      ## bail if we're headless
      return subject if not config("isInteractive")

PRs welcome

@kuceb kuceb closed this as completed Dec 6, 2019
@amfarrell
Copy link

amfarrell commented Jun 10, 2020

My use-case for this is to be able to tell someone:

You can reproduce the issue by doing
git fetch origin my-debugging-branch
git checkout my-debugging-branch
bundle exec rails server -p 3000 # Then in a separate terminal
yarn cypress run --no-exit --headed --spec=cypress/integration/bugs/reproduce_bug.spec.js

If I can have a single test pause at meaningful points with comments,
then I can use cypress as a walkthrough of a problem.
If I can specify the test path on the command line and have cypress immediately start running it, then someone who isn't yet sold on cypress does not have to hunt around the interface for the test that I point to, but can instead just run that command and see "woah, this is animating the browser in front of me and not flakey" just after copy-pasting commands.

This turns cypress into a tool for

  • Communicating about bugs
  • Getting myself or someone else set up to debug a problem on either client and server
    Allowing Cypress to demonstrate its value to new people.

My use-case might be better accomplished by adding a --spec argument to cypress open which would cause a particular test or set of tests to run immediately upon opening. Then I could do cypress open --detached --spec=cypress/integration/bugs/reproduce_bug.spec.js

@jennifer-shehane
Copy link
Member

Support for --spec during cypress open is another requested feature. @amfarrell Your use case makes a lot of sense. Thanks for explaining in detail.

@vitaliy4us
Copy link

vitaliy4us commented Jun 21, 2020

I need one of two possible ways to run a test containing pause() command:

  1. Use cypress run --spec "cypress\integration\mytest.js" --headed --no-exit which should not ignore pause() command
  2. Use cypress open --spec "cypress\integration\mytest.js" which starts the test containing pause() command automatically.

The reason is that I want to call the test from a script which automaticaly starts selected Cypress example. The test contains pause() to give user a chance to study example in details instead of "watching a movie" flickering in front of him for a couple of seconds

@amfarrell
Copy link

amfarrell commented Jun 25, 2020

The test contains pause() to give user a chance to study example in details instead of "watching a movie" flickering in front of him for a couple of seconds

This fits my use-case exactly.

Two other things:

  • cypress open --spec should probably default to only starting its run after it detects that the server is up.
  • Ideally, it could also take a --quiet option. That way, I could say something like

To reproduce this, git checkout my-branch and then run
cypress open --spec "cypress\integration\mytest.js" --detached --quiet && bundle exec rails s.

It will open chrome window that walks through the user actions to just before the issue.
Hit the "▶" button to the left of the URL.
It will continue the user actions that trigger the bug and pop rails into binding.pry where you can inspect the value of....

Django users can say an equivalent thing for runserver and ipdb.

I should create a separate issue for this...

@jennifer-shehane jennifer-shehane added the good first issue Good for newcomers label Aug 21, 2020
@LazaroOnline
Copy link
Contributor

LazaroOnline commented Nov 8, 2020

I would also like to be able to "pause" when running with cypress run --headed --no-exit.
In my case I use "pause" to manually enter a captcha during a semi-automatic test.
I need to use run instead of open because run supports other parameters like --spec so it runs without requiring me to click on the UI tests list.

Also, while cypress continues to skip the pause on run, could you guys at cypress update the documentation to reflect this?
I ran into the same issue and took some time to figure out.
https://docs.cypress.io/api/commands/pause.html

Thanks!

@Konstruktour
Copy link

Konstruktour commented Dec 11, 2020

as a workaround: set the config parameter Cypress.config('isInteractive', true); , then pause works like in the headed mode.

@diminutivesloop
Copy link

My use case is that I need to debug why a test is failing only in cypress run and not cypress open. I tried the solution offered by @Konstruktour but cypress run apparently doesn't take that config option anymore.

@Aleksandr-codefresh
Copy link

+1, in nrwl/nx environment, "cypress run" is the default command

For this specific use case solution would be to add --watch flag. Then it will run cypress in the interactive mode (see details).

@tristan-mastrodicasa
Copy link

My use case is that I need to debug why a test is failing only in cypress run and not cypress open. I tried the solution offered by @Konstruktour but cypress run apparently doesn't take that config option anymore.

In typescript and on the command line it complains that the 'isInteractive' option doesn't exist, but when you use plain js and put the line Cypress.config('isInteractive', true); in it worked as expected for me (v7.3.0) and the pause functionality was available.

This looks like another bug. It would be nice if this was properly fixed since I want to introduce to my company a new way to automate PR testing where the test is agnostic of the project.

@omgitsedwin
Copy link

My workaround was to overwrite cy.pause() when using the CLI:

cypress/support/commands.js

Cypress.Commands.overwrite('pause', (originalFn, subject, options) => {
  if (Cypress.config('isInteractive')) {
    return originalFn(options)
  } else {
    cy.task('pause')
  }
});

cypress/plugins/index.js

const readline = require("readline");
module.exports = (on) => {
  on('task', {
    pause() {
      const rl = readline.createInterface({
        input: process.stdin,
        output: process.stdout
      });
      return new Promise((resolve) => {
        rl.question("Press [Enter] to continue", (answer) => {
          console.log(answer)
          rl.close()
          return resolve(answer);
        })
      });
    }
  });
}

@vlad0337187
Copy link

vlad0337187 commented Sep 15, 2021

It just doesn't work.
It should be fixed.

yarn cypress:run --config video=false,isInteractive=true --headed --no-exit --spec <my_test.spec.ts>




Also didn't find any helpful commands or config options to avoid this in this thread.

Cypress logs: isInteractive is not a valid configuration option, so the only thing helped:

  • add Cypress.config('isInteractive', true) before .pause() calls
  • now pausing works
  • but .debug() won't work
  • in order for .debug() to work, you should open devtools from Cypress GUI main menu (probably when app is paused)
  • now .debug() works too

@cypress-bot cypress-bot bot added stage: backlog and removed stage: ready for work The issue is reproducible and in scope stage: backlog labels Oct 1, 2021
@cypress-bot cypress-bot bot added stage: needs review The PR code is done & tested, needs review stage: work in progress and removed stage: work in progress stage: needs review The PR code is done & tested, needs review labels Oct 6, 2021
@jennifer-shehane jennifer-shehane added stage: pending release and removed stage: needs review The PR code is done & tested, needs review labels Oct 11, 2021
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Oct 11, 2021

Released in 8.6.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v8.6.0, please open a new issue.

@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators Oct 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
good first issue Good for newcomers type: unexpected behavior User expected result, but got another
Projects
None yet
Development

Successfully merging a pull request may close this issue.