Brian Mann – I see your point, but… (Part 1)
Why Stack Overflow recommends it
Stack Overflow users link it as the go-to explanation of Cypress best practices, especially logging in via API requests instead of the UI and running independent, dynamic tests.
Recommended by 6 people across 6 different months, 2018 to 2023.
What it is
A 27-minute conference talk from AssertJS 2018 by Brian Mann, creator of Cypress, covering end-to-end testing practices. It is part 1 of a joint session with Gleb Bahmutov and touches on TDD versus E2E tests, stubs and mocks, and how to set up application state in tests.
What people said
Strong rec Afraz Ali · 2020-07 · Stack Overflow · on “What is the best practice for writing e2e tests that need to run in a sequence?”
Posting this for anyone else who stumbles upon this question in future and is considering Cypress.io for writing e2e tests. This blog post [LINK] on their website summarizes best practices of writing e2e tests. An excellent talk [this video] by Brian Mann shows best practices of writing e2e tests using Cypress.io Basically we can use commands in Cyprus to perform common actions that need to run before every test. Answer by Mudithra is perfectly valid for my question to explain in general how we should tackle scenarios where a test is a prerequisite for another test.
Strong rec Vadorequest · 2020-11 · Stack Overflow · on “How to dynamically generate test cases in Cypress?”
I wanted to do something similar. I went through all the links posted above and here are my findings: What you're looking for is called " Dynamic tests [LINK] " . Sometimes you want to iterate through a list of items, and for each item create a separate test. These tests are called dynamic tests. Examples of dynamic tests are: run same test against different viewport resolutions run same test against different sub-domains of your site generate tests based on the fetched data [LINK] Now, there are several ways of dealing with "dynamic data". I strongly advise to watch the talk of Brian Mann [this video] , author of Cypress. (2018, 27mn) He speaks about the 3 different ways of dealing with dynamic
Recommends Arnaud P · 2018-06 · Stack Overflow · on “Cypress and auth app with sections. Can you call a shared test, ie login?”
You understand you could create a command for login. Any reason for not doing so then ? If you haven't already, I recommend watching this presentation from Cypress's founder Brian Mann, referenced on one of the official doc pages [LINK] . Please find below two sections that seem to relate to your question. 3 strategies to test the login page (8:40) [this video] stub requests, don't actually authenticate OR static user in the DB OR dynamic user created by tests Centralize login (15:35) [this video] (9 minutes later) We don't have to , nor should you ever , use the UI to build up state
Recommends Jacob Bowdoin · 2018-07 · Stack Overflow · on “How to use Firebase Auth's Google Sign-In option with Cypress.io”
I need help using Google Sign-In when testing my Angular 6 app with Cypress. It can't use the sign-in popup, and so I'm trying to follow Cypress' advice to "always use cy.request() to talk to 3rd party servers via their APIs." That's from [LINK] which then points us to this example: [LINK] - more info on how to do this is seen at minute 23 in a presentation by the Cypress author: [this video] I'm taking the video solution and trying to modify it for Firebase Auth according to [LINK] but I'm getting stuck on how to obtain the proper id_token and so far I have this code in my commands.js file: Cypress.Commands.add('login', () => { var id_token = ___?____; cy.request({ method: 'POST', url: ' [LINK]
Recommends Yevhen Laichenkov · 2021-07 · Stack Overflow · on “Cypress beforeEach setup with cy.request”
Yes, it's a good practice. Read more here [LINK] . Also, you can watch a brilliant presentation by Brian Mann here [this video] . Keep in mind that tests should always be able to be run independently from one another and still pass. Read more here [LINK] .
Recommends Fcmam5 · 2023-02 · Stack Overflow · on “In Cypress, should assertions be kept within test blocks themselves, or should they be in helper functions/automation steps”
Your question is valid. You can create a custom action [LINK] for login, and indeed when working on bigger applications the impact of performing the login as an assertion gets more noticeable as we might cause some performance issues and make our test suites more time-consuming, plus this would mean that we have a dependency between our tests which is generally a bad practice [LINK] : Tests should always be able to be run independently from one another and still pass. So that's why the documentation [LINK] suggested this talk: [this video] Which talked about these recommendations: [LINK] Don't use the UI to build up the state, use it directly Don't share page objects to share UI knowledge, write
Cites dotnetspec · 2020-05 · Stack Overflow · on “Cypress test approach for testing with Metamask”
I want to test how my application interacts with Metamask (e.g. is the wallet open?) and create a flexible test configuration that enables me to access the application by 'mounting' the Metamask interface in a similar way to how ordinary 'login' is done (I use MM for login effectively) in the Assert JS (2018) lecture videos like: [this video] Is there any reference material or advice for testing Metamask with Cypress? Cypress has the following documentation for loading a Chrome extension plugin: module.exports = (on, config) => { on('before:browser:launch', (browser, launchOptions) => { // supply the path to an unpacked WebExtension // NOTE: extensions cannot be loaded in headless Chrome launchOp
Cites Ostn · 2020-05 · Stack Overflow · on “How to set state or dispatch actions from a navigator (ex : cypress testing)”
A good practice given by Cypress (e2e testing) is to set the state of the app programmatically rather than using the UI. This of course makes sense. On this video [this video] Brian Mann propose this solution to expose a Redux store : [LINK] Is there any possibility with NGXS to have access to the different state programmatically during testing ? An example is for the login process : dispatching directly a Login action or setting the store with the access token, to be logged in before any test, would be nice.
Cites binaryfunt · 2022-05 · Stack Overflow · on “How can I make part of my test reusable so that it can be used or called again in other future tests using Cypress Javascript”
See [this video] for an explanation of why you may not want to go down this route of replicating user behaviour to log in. Long story short it would be better to authenticate directly instead e.g. using a POST request.