feat(testing): include iOS and Android Browser for unit testing

[quantizor]

We currently have no coverage for mobile browsers, including tablets. This updated config will include
testing for iOS 6.0 and 7.0 (iPhone) and Android Jelly Bean (4.3) via Sauce Labs WebDriver.

[mary-poppins]

Thanks for the PR! Please check the items below to help us merge this faster. See the contributing docs for more information.

• Uses the issue template (#6578)

If you need to make changes to your pull request, you can update the commit with git commit --amend.
Then, update the pull request with git push -f.

Thanks again for your help!

[caitp]

I'm not sure we want to add this many browsers, testing these things isn't free, this might be a bit much, but I'll see what people think about it. As I said previously, we might prefer to do this testing for Angular 2.0, where mobile first is the big priority. I'll see what people think

[caitp]

Also, to run these browsers on travis, you need to add those browsers to scripts/travis/buld.sh

[quantizor]

Thank you - I'll do that now.

I would say limiting devices is probably a better idea than OS versions - so perhaps one Android 4.2 and one iOS 6 / 7 instead of testing both iPad and iPhone if you think it would be better to trim down the requests.

[quantizor]

Where do the BrowserStack tests get executed? I don't see a reference to any of them in that Travis file, only the SauceLabs tests.

[caitp]

We aren't currently running tests on browserstack, IIRC --- and yeah, looking closer at the change I see you're using BS browsers rather than SL. That may or may not be a problem, though

[quantizor]

Yeah, unfortunately Sauce doesn't support mobile browsers for Selenium testing at the moment.

[caitp]

We aren't using selenium for unit tests, I don't think this is a huge problem

[quantizor]

Ah, so this PR is kind of unnecessary then? Seems strange to have the infrastructure for BS in there but not be using it.

[caitp]

We aren't doing a lot of E2E testing in angular currently, the vast majority of testing is unit tests, and does not depend on selenium at all. Down the line it might be nice to add mobile selenium tests where possible, but since we aren't doing a lot of integration testing, this is not a huge problem.

So no, the PR isn't really "unnecessary", it would be a good thing to run unit tests on mobile devices. The question is whether we want to do that in the 1.x cycle, or further down the line, and how frequently mobile tests should run.

[IgorMinar]

@vojtajina do we want this PR?

@3lux @caitp we have browserstack config for some browsers because we were actively exploring possibility to run tests on browserstack. we hit some issues, so that's on hold for now and we use saucelabs instead. It's my understanding that saucelabs does have mobile devices or emulators available for us, but I haven't tested that personally.

and regarding selenium - SauceLabs offers all of the browsers via WebDriver api, which is often called Selenium for historical reasons. We don't use the selenium assertion library for any tests, WebDriver (part of the Selenium project now) is a low level communication protocol that allows us to remotely control browsers)

[quantizor]

@IgorMinar Ah! That makes more sense. I'll revise my PR to use the WebDriver tests instead with the reduced set we touched on @caitp

[quantizor]

So this looks good - there are Android unit test failures that need to be looked into, but the code to enable the tests in the first place seems to be working.

[Narretz]

We are currently running on iOS, and since Android browser is Chrome based, I don't think it adds a lot of value to test this additionally.