Protractor Selenium IDE And Easy e2e Tests

[Owen M]

Wondering what people are doing to make e2e writing easier/faster/... ? What is your workflow to create e2e tests with Protractor?

Was looking at Selenium IDE where you can record a series of actions. Seemed promising for really easy e2e testing.

1. Load your app in Firefox with Selenium IDE
2. Record a series of actions by simply performing the action on the page
3. Export the generated script
4. Tweak as needed, especially when fragile selectors/actions are generated

Idea is to save having to write all tests by hand. Some you'll need to, but basic things an approach like the above would be better. Plus the easier and faster it is to create tests, the more get written which is a big win.

Problem with the above is that I couldn't find a Jasmine or even JavaScript export (even digging through other plugins). I could write an export plugin probably, but wanted to know if I'm missing something obvious. A quicker, but not so elegant approach, would be to convert say the Python WebDriver export into a Jasmine like test case.

So to the original question, how are people creating Protractor e2e tests? Any tips or tricks to make them painless as possible?

Cheers,

~Owen

[Owen M]

Spent a little bit more time on this. Found Selenium Builder, which can export a protractor test.

http://sebuilder.github.io/se-builder/

Not quite there, but could be a nice leg up for people, or a way to make some e2e test writing faster.

[Ethan Winters]

How has this been working for you? Obviously a huge departure from Protractor style tests.

[Owen M]

I moved away from this as I found the tests too brittle. Most used xpath which is great for quickly making selectors, but any changes to the webpage and the tests break. CSS selector generation is a bit better, but not much.

My flow for writing tests is basically:

1) use the element explorer script to create/test selectors on the page

2) Use those selectors to create "page objects”

3) Put those page objects into their own files, then use require() to load them into tests that need them (since it’s NodeJS under the hood)

4) Write tests against page objects

Bit slower to write tests, but break way less. We’ve already done a major change to the UI, and only had to change a handful of page objects and the tests were back up and running.

Perhaps there are better ways, but that’s working ok for us.

Cheers,

~Owen