Protractor tests with multiple chrome profiles

[jkirkpatrick]

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.

[btford]

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

[btford]

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]

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]

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]

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.

[souravghosh16]

ok