This repository was archived by the owner on Oct 18, 2025. It is now read-only.

Protractor tests with multiple chrome profiles#197

Open

jkirkpatrick wants to merge 4 commits intoangular:master from

jkirkpatrick:qa

Open

Protractor tests with multiple chrome profiles #197
jkirkpatrick wants to merge 4 commits intoangular:master from
jkirkpatrick:qa

Conversation

@jkirkpatrick

Copy link

@jkirkpatrick jkirkpatrick commented Dec 13, 2014

Runs the protractor example (using an example on the https://angularjs.org homepage). Uses webdriver and selenium for automatically launching and running tests in chrome (#193 and #194).

gulp profile1 or npm test will load profiles/protractor.config.js and use the default chrome data directory/profile.

gulp profile2 will load profiles/another.config.js and use the data directory specified therein (edit path prior to use). Note that the first time I ran it seemed like the browser just 'hung', but I think that was due to another extension looking for updates.

Tests are located in the tests directory.

Review on Reviewable

jkirkpatrick added 4 commits

December 12, 2014 22:07

@jkirkpatrick


 Setup travis and mocha

1e76755

@jkirkpatrick


 removed mocha added protractor

c49fcfb

@jkirkpatrick


 remove travis add multiple chrome profiles

d812876

@jkirkpatrick


 Added testing info to CONTRIBUTING

9287bb6

This was referenced Dec 13, 2014

test(e2e): run instrumentation against live sites running Angular #193

Open

Setup travis and mocha #196

Closed

@btford

Copy link

Contributor

btford commented Dec 13, 2014

Thanks, @jkirkpatrick! I'm going to spend some time going through PRs this afternoon.

@btford

Copy link

Contributor

btford commented Dec 15, 2014

This needs some work, but it's close.

One challenge is that we can't (AFAIK) run our own profiles on saucelabs, so this won't work well in a CI environment.

@btford

Copy link

Contributor

btford commented Dec 15, 2014

I really just want to know that instrumentation code works on real angular apps. Rather than use a Chrome profile that loads the extension, I'm wondering if using a proxy server that inlines the instrumentation might be a better bet.

@jkirkpatrick

Copy link

Author

jkirkpatrick commented Dec 15, 2014

That might work, I'm still learning my way around the code base so you'll have to excuse my ignorance. There's a lot of nuance in the project, and I do not want to make a bunch of mistakes.

IMO, final QA for desktop apps is un-possible with existing CI tools since they're mostly designed for webapps and mostly garbage for everything else except testing of API's. It's a PITA to test clean startup/shutown of a daemon with e.g. Travis, but trivial with a bash script. Even for relatively simple mobile apps, there's a bit of cross-platform infrastructure required (e.g. Jenkins on a Mac Mini for iOS.) For automated testing of desktop apps or embedded systems, I've always used tools installed on a local dedicated "testing" machine along with some dogfood test scripts.

I think the best-possible solution will require 2 (or 3) separate testing loops, one that can be fully automated and one that will require manual intervention (but used less frequently).

I can cleanup the code later this week and add some more tests.

@btford

Copy link

Contributor

btford commented Dec 16, 2014

I think the best-possible solution will require 2 (or 3) separate testing loops, one that can be fully automated and one that will require manual intervention (but used less frequently).

Ideally the whole thing is automated, but I agree that there will need to be more than one type of test.

I just landed e902eca, which unit tests some of the components of the panel app.

The next step will be integration testing the instrumentation code against real apps. The angular-hint repo already tests against test fixture apps, so I think we're pretty close on having that in a good state.