You changed beforeAll to before, maybe you need to do the same for entities: https://github.com/wmarques/generator-jhipster/blob/ng-mocha-protractor/generators/entity-client/templates/angular/src/test/javascript/e2e/entities/entity.spec.ts.ejs#L52 ?

@pascalgrimaud Yep I need to update entities, I'll do that tonight

@wmarques : can you resolve merge conflict plz ?

@pascalgrimaud Done, hope the tests will pass this time !

I'll try to fix this asap, seems we have to tell Protractor to wait after entities test, he's probably clicking "too soon"

It works on my computer so I don't understand what is going on... Maybe I should add browser.sleep(1000)? But I'm not a fan of that kind of solution...

@wmarques : I'll have a look. I have some strange timeout in Travis with NPM, that I didn't have so much with Yarn

@pascalgrimaud The failing test is the one when you the user types "admin" and "admin" as user/password and then we expect to have the green message that tells a successful login.
Maybe the backend takes some time to respond and protractor is checking too early for the message...
I can also try to tell protractor "wait for the message" before the assertion.

I had a look on this:

• there are some error during npm run lint, with No valid rules have been specified in log
• so npm test failed

Finally green ! 🎉🎉

@wmarques this is totally awesome work -> can you fix the conflict? Then I think it's ready to merge

@jdubois done !

@wmarques : you worked hard on this. Don't forget to claim the bounty :-)

Just to give my 2 cents here (I am not involved at any level with them) -> I personally use https://www.cypress.io/

Works with every framework, works on docker, hast fixtures, gui app... Learning curve was very low... If you like have a look, maybe for jHipster 6 ;)

I agree, exept with 1.
Protractor startup takes ages, cypress can execute 100 tests while protractor is loading :)
My experience was that protractor performance is horrible (and you dont get the power, tools and simplicity of cypress)

For me, startup time was never an issue and when you have a lot of e2e cypress really takes time. But I dont hold those gainst cypress its much more easier to use and debug than protractor. But then this is a lot of work and I dont think any of the core team members have the bandwidth for this

@hdurix Also told me about Cypress, I have to check this :)
One of the advantage I see with Protractor is that it automatically "waits" for Promises and Timeouts so we don't have to manage the API loading etc... But it only works for Angular if I'm right so if we want to merge the end-to-end tests for all frontend frameworks, it won't be an advantage :(

BTW, we can also use Jest + Puppeteer

Last time when I looked into Cypress, they didn't had much support for cross browser testing (mostly chrome flavors).

Indeed I also use Cypress with Vue.js at work and I also think it's nice!
It can be slow as human speed but it can be configured: for instance, the typing is done 1 letter every 10ms, but it's configurable.
And I didn't know about parallel testing, it's a big point.

IMHO, Protractor is a lot better than cypress for Angular because it hides a lot of complexities for developer. For the other frameworks (react and maybe Vue.js soon?), I think both have got pros and cons and are quite equivalents.

Below a table about how I see the options we have:

• Switch from Protractor to Cypress will ask work for not a better end use satisfaction (at least for Angular apps).
• Use Cypress for react will represents a lot of work as well (for coding and maintaining it).
• The perfect solution would be to ask for the wanted tool during generation but the amount of work would be huge for creating and maintaining purposes.

As @deepu105 said, all is about time and priorities. We can imagine a Cypress module if someone is interested to do it.

Protractor is an option here, that means doing cypress as a module should be doable !

My comment was just an "option for the future", I think jumping on it at this moment maybe is not (yet) a good idea, at least until they have firefox support.

Cypress can be used with any framework with any backend and because of that it would be an ideal candidate for jHipster.

So the end result could be : there is one codebase for e2e for all jHipster frameworks - cypress,

Whatever framework jHipster is supporting today or will support in the feature (Angular, React, Vue, jQuery, frameworkXY...) it does not matter - as long as some html ids, classes or attributes and url routes stay the same in every framework generated project.

Also (I assume) 90% of people build their jHipster project in jenkins (and other CI tools) and probably love (as much as I do) the fancy video recording feature. Analyzing the problem (reconstructing) becomes so easy and simple when you see what actually happened with the complete app step by step and how you came to the problem. This is a part protractor cannot cope with, you have to analyze the logs, find the test code and understand what you wanted to do in this test. Then you recreate that propbably manually on the UI. Then you verify... yes it is not working.

With cypress -> I watch the video, I see what the user has done to make it not work, then I go into code. I think this is a huge difference (maybe only my opinion but... isn't this how we imagine perfect e2e tests?).

I totally agree that cypress can be slow when you write 10000 tests with it but it can also be powerful and it depends how you write your tests.