batarang
batarang copied to clipboard
angular
Protractor tests with multiple chrome profiles
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.
Thanks, @jkirkpatrick! I'm going to spend some time going through PRs this afternoon.
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.
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.
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.
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 e902ecae968b44e1f3f000b41f104aa29b8a1e18, 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.