to run only one file

cypress run --spec path/to/file.spec.js

or using glob patterns:

cypress run --spec 'path/to/files/*.spec.js'

Note: you need to wrap your glob patterns in single quotes to avoid shell expansion!

to run only one test in a file

You can use a .only as described in the Cypress docs

it.only('only run this one', () => {
  // similarly use it.skip(...) to skip a test
})

it('not this one', () => {
})

Also, you can do the same with describe and context blocks

edit:

there's also a nice VSCode extension to make adding/removing .only's easier with keyboard shortcuts. It's called Test Utils (install with ext install chrisbreiding.test-utils). It works with js, coffee, and typescript:

After using several test frameworks, I feel the below is better:

For test file names, use as below:

1. /test/*.test.js - preferred, no need to explain.
2. /test/*.spec.js - OK, but new joinees always ask me - why?. A spec here means requirement specification.
3. /test/*.test.txt - preferred, if test cases are in a text file. A set of line(s) is a test case (see below).

For example:

• a.js is the main JavaScript file that should be tested
• /test/a.test.js is the test file that tests above a.js. Note that /test/ is a test folder.

You may find *.test.txt new, so adding more details.

The format of one test case being three lines, can be in the below format in *.test.txt:

• inputParam1 - may be the first parameter of a critical function which needs many tests
• inputParam2 - may be second parameter of a critical function which needs many tests
• expected
• inputParam1
• inputParam2
• expected
• ...

So, every three lines make one test case.

You may add the function name line like below, once in a while, which tests different function:

• -func:someMethod1
• ... (above input/expected lines)
• -func:someMethod2
• ... (above input/expected lines)

To execute a function name, or create a new object to a class, you can use eval(className), someMethod1[inputParam], etc. Though eval is not recommended, I use it as it is test framework which is not the production file. You will better ways than eval though if that is a concern.

After using several test frameworks, found this text file testing, by far most convenient for some special cases. (No need to format in JavaScript, JSON, etc.)

If you need, you may ignore that start with #, or //, or all blank lines.

So, I wrote my own framework that works this way.

• If you know a test framework that can read above format for *.test.txt, do comment below.

• Ping me if you need my code, will share via GitHub.

Just reverse the command

npx cypress open 

I'll just add that if you decide to do if condition by checking the .length property of cy.find command, you need to respect the asynchronous nature of cypress.

Example: Following condition evaluates as false despite appDrawerOpener button exists

    if (cy.find("button[data-cy=appDrawerOpener]").length > 0)    //evaluates as false

But this one evaluates as true because $body variable is already resolved as you're in .then() part of the promise:

    cy.get("body").then($body => {
        if ($body.find("button[data-cy=appDrawerOpener]").length > 0) {   
            //evaluates as true
        }
    });

Read more in Cypress documentation on conditional testing

Update: document.body.click will work in a browser, but for jsdom you need to manually create the event:

document.body.addEventListener('click', function() {
  console.log('test');
});

var evt = document.createEvent("HTMLEvents");
evt.initEvent("click", false, true);
document.body.dispatchEvent(evt)

The above code is working for me in Jest and should work with "solo" jsdom as well.

Autumn 2018 holiday update ????

The tools around simulating events have gotten a great deal better. I've currently shifted my approach to use the excellent react-testing-library to render my components and dispatch events:

import {render, fireEvent} from 'react-testing-library'

test('example', () => {
  const handleClick = jest.fn()

  const {getByText} = render(<div><button onClick={handleClick}>Click Me</button></div>)
  fireEvent.click(getByText('Click Me'))

  expect(handleClick).toHaveBeenCalled()
})

While I still believe in end to end tests with something like puppeteer or selenium (or cypress!) provide the highest level of confidence that something actually works, this provides a huge amount of value without polluting tests with manual event creation.

You can have Cypress retry the expectation by changing .then() to .should().

I would also change the order you obtain the elements, since .should() retries the preceding command only.

it('should center the spider by left border', () => {
  cy.get('.wall').then(($wall) => {
    cy.get('.spider')
      .should(($spider) => { // repeat .get(spider) until except succeeds, or times out
        ...
        expect(spiderLeft).to.equal(spiderLeftAbs);
      });
  });
});

Also works with triggerable transitions, I tested with a hover transition (using cypress-real-events).

<style type="text/css">
  .target {
    font-size: 14px;
    transition: font-size 1s 1s;
  }
  .target:hover {
    font-size: 36px;
  }
</style>

BTW you may need to use some +/- on the pixels.

Try to run again without import {cypress as cy} from "cypress"

This answer provides most of the information needed (thanks CRayen for pointing me to another question (which was a duplicate of another)).

Basically you can put a .eslintrc file into any subfolder in which you want to override rules. Then you need to add a section like the one in the answer:

"overrides": [{
  "files": [ "*.spec.js" ],
  "rules": {
    "no-unused-expressions": 0
  }
}]

where you explicitly turn off the rules you don't want to be used to check the files listed by setting them to 0.

pass input change to state => when state changes there are life cyclehooks that fire, handle logic there.

Not sure what you're trying to do but vanilla javascript should be sufficent

What are you trying to do on a submit? what event are you tracking?

I'll try to help you more after I get some clarification

Thanks :)