Cypress: `pause()` should not be ignored with `cypress run --headed --no-exit`

Created on 28 Apr 2019  Â·  23Comments  Â·  Source: cypress-io/cypress

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

first-timers-only ready for work unexpected behavior

Most helpful comment

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.

All 23 comments

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

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... :smile:

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.

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

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

@Bkucera I ran into the same problem as https://github.com/cypress-io/cypress/issues/1669#issuecomment-500675785 did.
So I have to use cypress run to run my case

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

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?

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.

Why cypress is putting in the reports and even launching the UI for those tests that are excluded by tag filters? (Using cucumber plugin)

@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.

@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.

@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

@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')

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

@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

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.

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

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

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

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

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...

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!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

EirikBirkeland picture EirikBirkeland  Â·  3Comments

rbung picture rbung  Â·  3Comments

carloscheddar picture carloscheddar  Â·  3Comments

tahayk picture tahayk  Â·  3Comments

weskor picture weskor  Â·  3Comments