https://cypress.io logo
Join Discord
Powered by
# help
  • g
    I see I see, do you know if that costs?
  • s
  • g
    thanks 😄
  • f
    One thing with this implementation: I'm pretty sure that Cypress dashboard runs specs in parallel, not individual 
    it()
    blocks
  • g
    thats good to know, btw is it normal that headless takes longer to execute compare to cypress open? for some reason it takes veryyy long time to execute headless for me and also lags the whole computer
  • f
    Shouldn't be the case, no. I take it you're running Chrome for 
    open
    and defaulting to Electron for 
    run
    ?
  • g
    I did 
    cypress run --headless --browser chrome:beta
  • c
    Ive tried that but what i want to know is if a specific string is contained within a console log. e.g. expect(win.console.warn).to.contain('i18next') how would i do that as ive tried this.,
  • f
    In that case, I'm not sure. Best checking with support (another perk of having a paid Cypress plan 😉 )
  • g
    oh wow, it worked instantlty if I removed :beta at the end
  • f
    cc @adventurous-dream-20049 You could be facing some perf issues with the Chrome beta
  • g
    Since you mentioned this before - What other suggestion would you think of if I want to run e.g. 2 URLS given in or command and then execute the same test pararell with each of their own URL?
  • f
    I can think of a couple of ways. Depending on the number of URLs you're going to be visiting, it might just be easiest to have two separate spec files, one for each URL
  • g
    Lets start by having just 2 urls as for starters
  • f
    Keep it simple IMO. Have two spec files. One for each URL. Alternatives just seem like more hassle than they're worth: -If you're going to try doing stuff like pass the url in the 
    it()
    , you'll not be able to parallelise with the dashboard -You could try having separate 
    cypress run
    commands for each 
    baseUrl
    , but given that the run commands will point to the same spec file I don't know if Cypress Dashboard's orchestration will work as expected
  • c
    This code 
    expect(win.console.log).to.contain('i18next');
    is giving me this error 
    object tested must be an array, a map, an object, a set, a string, or a weakset, but function given
  • g
    and when you say "have two spec files" what are you thinking about then? I dont think I have any spec file myself at all now and I wonder how can I use two in that case?
  • f
    You will definitely have spec files if you already have a running set of tests. I'm talking about the files that house the cypress scenarios (
    it()
    ) within a 
    describe
    block. Normally called something like 
    testname.spec.js
  • g
    are you thinking about the e2e test then?
  • f
    yeah
  • g
    So basically copy the same test and just change the visitUrl?
  • f
    Yep. Seems like the simplest way to me. If you wanted to reduce duplication, you could place most of the steps in a cypress command and call that.
  • g
    Because my first thining was to have a command where I can do something like cypress --config url=['https:1, https:2] and that will then run pararell for each URL
  • g
    Or whatever that is most possible in that case
  • f
    So how would you handle parallelisation in that case?
  • g
    It could be fine to have also like Bennymeade mentioned, to have it in a JSON file and then read it but again, Im trying to make it work more pararell rather than run one by one
  • g
    Im not really sure, I think im overthinking at this point alot
  • f
    Bennymeade's solution is cleaner, but they won't run in parallel
  • f
    Anyway, separate spec files is what I'd go with. If you find another solution that's cleaner and allows for parallelisation, let me know
  • g
    Yeah, Im just thinking, because if I run e.g. 10 urls. Having 10x of same .specs would be harder to maintain. No?
1...120121122...252Latest