cy.request
from Cypress to authenticate as
a new user
./cypress
folder, including a folder for
integration tests, fixtures, plugins,
and support.
calculator.js
cy.visit()
in order for Cypress to know what to
render for integration tests to be
written.
cy.visit('http://localhost:[port]')
once our server is running.
cypress
folder created when first run.
e2e
. Cypress won't know about this
change until we specify to use the
folder. We can do so by adding and integrationFolder
property to our cypress.json
.
.get('.my-selector')
. We can trigger a click on it with .click()
. We can run assertions on elements
using .should('[assertion.command]',
'value-to-compare')
.
cypress.json
.
http://localhost:8080
to all of our tests in cy.visit()
, we can configure a baseUrl
property that will be used in our tests,
for which we can provide only
paths.
baseUrl
overcomes this.
calculator.js
test in cypress/integration
into cypress/e2e
to better describe the intent of our
tests.
cypress/integration
, so we'll need to configure the integrationFolder
viewportWidth
and viewportHeight
properties in the config to specify our
own dimensions.
.get()
commands in our calculator test are
pretty nasty. We can leverage cypress-testing-library
to benefit from commands similar to
those in react-testing-library
.
cypress-testing-library
is installed, we need to extend cy
's commands. This is done by
importing commands into cypress/support/index.js
. We import cypress-testing-library/add-commands
here.
.get()
to .getByText
, .getByTestId
etc.
start-server-and-test
to start our server, wait for the app to
be accepting requests, run Cypress, and
then kill our server.
cypress run
runs tests on Cypress without the
UI.
is-ci
, start-server-and-run
, npm-run-all
, and separating our scripts we can
simplify running our application and
tests at the same time.
.then
that accepts a subject and returns it.
Inside this statement you can place a debugger
statement.
Cypress
object to the global object which can be
used in tests to determine whether a
file is being executed in the context of
Cypress or not.
register.js
test-data-bot
we can generate credentials for users
using faker
s API.
.type('text to type')
command once we have a subject (an
element).
.url().should('eq',
myUrl)
Cypress.config()
window
object using .window()
to make it the subject.
.its('property[name]')
command:
.should('be.a',
expectedType)
register.js
login.js
register.js
. We don't yet have a user, so we
need to first register the user, and
then go through the log in flow using
the same credentials.
login.js
login.js
we've duplicated the registration
flow. This makes maintaining the tests
more difficult when there are changes or
errors, and we're just doing the
same work again.
cy.request(options)
.
login.js
is convenient, but if other tests need a
user to be created, it can quickly
become tedious to repeat the same
process.
cypress/support/commands.js
:
cypress/support.commands.js
commands.js
file in the support
folder, and then reuse the custom
commands in our tests.
calculator.js
cy.request
from Cypress to authenticate as a new
user
calculator.js
login.js
.
cy.request
to make a request directly to the API,
and then use window.localStorage
to set the token in localStorage
, before running any assertions.
commands.js
calculator.js
calculator.js
will likely be needed by other tests, so
we can create a custom command to reuse
it later.
commands.js
calculator.js
window
.
window.__REACT_DEVTOOLS_GLOBAL_HOOK__
. To provide context within the iframe,
we need to set that variable to that of
the parent window (where React has
defined the variable):