Great Guys! Thanks for the feedback. I'll move forward as discussed. Thx
On Wed, Sep 26, 2018 at 11:44 PM Michael Miklavcic < michael.miklav...@gmail.com> wrote: > I'm good with it. We can see some tests in action (and hopefully running in > Travis! :-D) and then migrate and deprecate Protractor accordingly if we > still agree that's the way to go. When you submit the first PR, please link > to this DISCUSS via permalink from the mailing list archives. Thanks guys. > > Cheers, > Mike > > On Wed, Sep 26, 2018 at 7:17 AM Shane Ardell <shane.m.ard...@gmail.com> > wrote: > > > I think Tibor's idea of using PCAP tests as an introduction to Cypress > for > > Metron is a great idea. As he pointed out, PCAP tests can take advantage > of > > Cypress' capability to mock responses, and we can set it up to run in > > Travis. Once the community is able to see the benefits from an actual set > > of Cypress tests inside the project and running in Travis, I think any > > questions about migrating the rest of the existing tests from Protractor > to > > Cypress will be settled. However, if for some reason we run into issues > > implementing or running the tests, we will have invested a fraction of > time > > vs. migrating all the tests right away. > > > > On Wed, Sep 26, 2018 at 2:12 PM Tibor Meller <tibor.mel...@gmail.com> > > wrote: > > > > > Hi Team, > > > > > > Many of us agreed on that Cypress could be a more capable tool for us > to > > > write high-level UI tests, whether those be e2e, integration or > automated > > > regression tests. If there is no open question left about cypress we > > could > > > to bring it a test drive. My suggestion is to implement the PCAP UI > tests > > > with Cypress. Some services and PCAP semple data yet not available from > > our > > > CI environment so protractor is hardly applicable here. This would be a > > > great opportunity for cypress to shine. With Cypress, we are able to > mock > > > out those responses and make it run in Travis. > > > Anytime we make PCAP data available in Travis we could be able to plug > > out > > > those mocks and run the same test as integration or e2e tests if we > like. > > > > > > Because it is relatively easy to migrate across cypress and protractor > I > > > see no major risks here if we decide to stick with Protractor for some > > > reason. > > > > > > What do you think? > > > > > > Thanks for your feedback, > > > Tibor > > > > > > On Wed, Sep 19, 2018 at 1:49 PM Shane Ardell <shane.m.ard...@gmail.com > > > > > wrote: > > > > > > > Hello everyone, > > > > > > > > Currently, we use Protractor to run our UI "end-to-end" tests. > However, > > > > there are a handful of major advantages we can gain from switching to > > > > Cypress: https://www.cypress.io/features/. > > > > > > > > - As with most Selenium-based e2e testing frameworks, Protractor > > > suffers > > > > from test flakiness. This is because Selenium runs outside of the > > > > browser > > > > and executes remote commands across the network. To work around > this > > > at > > > > the > > > > moment, we are using protractor-flake to re-run failed tests, but > > this > > > > is > > > > more of a crutch than a fix. Cypress executes in the same run loop > > as > > > > the > > > > application it's testing, and as a result does not suffer from the > > > same > > > > flakiness. > > > > - As a result of its architecture, Cypress runs much faster than > > > > Protractor. This is especially critical if e2e tests are added to > > the > > > CI > > > > build in the future. > > > > - Protractor is incredibly hard to debug. In contrast, Cypress > comes > > > > with a plethora of debugging features, some of which you can see > in > > > > action > > > > here: https://vimeo.com/242961930#t=264s > > > > > > > > Does anyone else have thoughts or opinions on switching to Cypress or > > > > staying with Protractor? > > > > > > > > Cheers, > > > > Shane > > > > > > > > > >
