https://cypress.io logo
Join Discord
Powered by
# general-chat
  • b
    thank you !!!
  • s
    Yey!!
  • d
    This is the actual page and in cypress getting blank page
  • p
    whot whot
    Copy code
    You can now run tests in Webkit, Safari's browser engine, by enabling the experimentalWebKitSupport experiment and installing playwright-webkit. For more details, read our blog post. Addressed #17336.
    b
    • 2
    • 8
  • p
    Hi I am fighting to display text visible
  • p
    whot whot
  • m
    Copy code
    Hey, I'm a Full Stack & BlockChain developer and looking for a new part time or full time position.
I'm strong in react, vue for front-end and pretty good with Rust, Solidity, SmartContract, Defi apps.
Do you have any position for me? 

Thanks
  • m
    @adventurous-dream-20049 @lemon-oyster-64925
  • l
    We have the #882359988385906708 channel in which people post open and upcoming jobs. Take a look there for something that may fit your skillset!
  • f
    I'm having a problem running cypress tests on github pipeline, especially with cy.intercept() and cy.wait() are giving me timeout error. I've added more details here. https://stackoverflow.com/questions/73717738/cy-intercept-not-working-in-github-pipeline Have any of you encountered the same issue before?
  • b
    hey all, I was wondering what kinds of solutions folks have been using for SMS testing? We have a lot of test cases that involve sms (fetching codes, responses, etc) and we're running into the issue where too many tests are hitting too few SMS numbers, causing tests to fetch the wrong messages. Seems like the best case scenario would be a single sms number per test case, but not sure thats feasible financially
  • c
    Hi all, can I store an event listener in a constant and import it into a spec file? Something like const onFail = Cypress.on('fail', (result) => { // Do something }) export default{ onFail } Then import it. For some reason it is passing my tests without running them
  • f
    I'm extremely excited to see that we have someone from Antartica here!
  • g
    That's cold 😉
  • q
    Hi folks, getting this on our build agent ONLY for e2e tests (component work fine), and also unable to repro locally. "Cannot find module" in various spots in /Cypress. Happens after the upgrade to Cypress 10 from 9, on the 
    npm run build
    step before starting up the tests. Any ideas?
  • l
    Hello folks. I'm curious if someone can help me understand why retries (set in config) won't retry on 
    before
    and 
    after
    , but will on 
    beforeEach
    and 
    afterEach
    hooks. We use a command to signup/login a new user 
    before
    each test suite that can be used throughout the tests. Sometimes the assertions fail though because not everything has been returned from the API. I have a 
    {timeout: 10000}
    on the dashboard, but it still fails once in a while. As far as I can tell it's like the API goes to sleep if nothing has interacted with it for a while. So the test fails at the 
    signup()
    phase. But it will always work on the second run. https://docs.cypress.io/guides/guides/test-retries#How-It-Works
  • f
    You're doing login once in a before? Or you're doing login once in every beforeEach?
  • f
    Your question seems to imply both
  • q
    I'm guessing this is because this runs before the whole suite, there is no "test" to retry. Maybe you can work around it by running your 
    signup()
    in a beforeEach, and pulling from cache if it has already run successfully?
  • f
    That is the correct answer, but it seems as if he's saying that he's doing it before every spec, so that's why I'm confused.
  • f
    It would make me think he's using 'before:spec' but if so, you could just move to a beforeEach
  • l
    Sorry for the confusion. No it's just calling the 
    signup()
    command in the 
    before
    . Then we go on to run various 
    it()
    blocks.
  • q
    I would probably move it to a beforeEach and inside your signup method just pull from cache if it's already run successfully so you don't have to do the expensive part each time.
  • l
    Interesting. So there's some kind of implementation I can use that says, "if this has already run, don't bother, here's the info you're looking for."?
  • q
    yeah you'd have to build it
  • q
    inside signup(), you'd do: if i already have a token/whatever stored, then don't go call the signup API and just return the value from last time.
  • l
    Awesome. Okay. I will try that out. Thanks for the help!
  • f
    To be fair, the before should work in your case too. I'm assuming that's an entirely different thing though, but @little-france-10142 already answered it as well
  • f
    If your "before" fails, the entire runner won't run afterwards because no spec had ran and the runner promptly stops, so there is no "retry"
  • l
    That makes sense. There's nothing to even kick off 
    before()
    . Whereas 
    beforeEach()
    will run without an 
    it()
    block below.
1...818283...127Latest