Moving to mobile-l
Setting the cookie mf_useformat ensures that the mobile site gets loaded. If tests are run against en.m. etc.. this won't have any effect, but a lot of local instances are setup to run the desktop URL by default. An alternative way of doing this would be to toggle to the mobile site explicitly in the test suite.
e.g. Given /^I am in the mobile view$/ do on(ArticlePage).switch_to_mobile_element.click end
In terms of 2nd question - no I don't think we should abandon trying to test Nearby in the browser, it is one of our most important features and has extremely inadequate test coverage and is one of the things that seems to break the most. Even if the test only works for Firefox, having that test is a good thing.
On Tue, Mar 18, 2014 at 11:03 AM, Chris McMahon cmcmahon@wikimedia.org wrote:
I should also mention that part of the change is to update the mediawiki-selenium gem to version 2.13. This should make the no_javascript tests pass again (along with some similar tests for ULS).
On Tue, Mar 18, 2014 at 10:36 AM, Chris McMahon cmcmahon@wikimedia.org wrote:
Hi Mobilers,
Željko and I have been doing a ton of refactoring, moving shared code out of the repositories and into the mediawiki-selenium gem, and removing cruft along the way.
We've got the code that makes the user agent spoofing into the gem because MobileFrontend and ULS share that code.
We'd like to remove some more code that we believe to be unused, but we need to talk about it here first before that happens. The change is https://gerrit.wikimedia.org/r/#/c/119271/
The first question is: is it necessary to set the cookie "mf_useformat"? We don't see that affecting the outcome of any MF tests. If so, we should make that shared code and not hard-code the name and value of the cookie.
The second question is: should we abandon trying to test Nearby in a browser? Besides the problems of variable geographic data in both the browser and the target wiki, testing Nearby also relies on managing a SQLite file containing a Firefox profile and manipulating the contents of that file. Even if the test worked, it would only ever work for Firefox. It may be better to test that feature below the browser with appropriate mocks and stubs and what have you.
On Tue, Mar 18, 2014 at 11:36 AM, Jon Robson jrobson@wikimedia.org wrote:
Moving to mobile-l
Setting the cookie mf_useformat ensures that the mobile site gets loaded. If tests are run against en.m. etc.. this won't have any effect, but a lot of local instances are setup to run the desktop URL by default. An alternative way of doing this would be to toggle to the mobile site explicitly in the test suite.
I guess I thought it was redundant because of the line in url_module.rb ""#{mediawiki_url}#{name}?useformat=mobile"" accomplishes the same thing. Although maybe you need the cookie if you follow a link out to a new URL? Just guessing.
In terms of 2nd question - no I don't think we should abandon trying
to test Nearby in the browser, it is one of our most important features and has extremely inadequate test coverage and is one of the things that seems to break the most. Even if the test only works for Firefox, having that test is a good thing.
Does anyone think this would be better tested below the UI level?
-Chris
Nearby already has pretty complete unit tests, but these appear to be working inadequately... Usually the things that break are simply loading it in the first place which can really only be tested with a browser test.
On Tue, Mar 18, 2014 at 11:46 AM, Chris McMahon cmcmahon@wikimedia.org wrote:
On Tue, Mar 18, 2014 at 11:36 AM, Jon Robson jrobson@wikimedia.org wrote:
Moving to mobile-l
Setting the cookie mf_useformat ensures that the mobile site gets loaded. If tests are run against en.m. etc.. this won't have any effect, but a lot of local instances are setup to run the desktop URL by default. An alternative way of doing this would be to toggle to the mobile site explicitly in the test suite.
I guess I thought it was redundant because of the line in url_module.rb ""#{mediawiki_url}#{name}?useformat=mobile"" accomplishes the same thing. Although maybe you need the cookie if you follow a link out to a new URL? Just guessing.
In terms of 2nd question - no I don't think we should abandon trying to test Nearby in the browser, it is one of our most important features and has extremely inadequate test coverage and is one of the things that seems to break the most. Even if the test only works for Firefox, having that test is a good thing.
Does anyone think this would be better tested below the UI level?
-Chris
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Tue, Mar 18, 2014 at 2:22 PM, Jon Robson jrobson@wikimedia.org wrote:
Usually the things that break are simply loading it in the first place which can really only be tested with a browser test.
Can "loading it in the first place" be tested without having to maintain a custom profile for Firefox that overrides default settings for access to browser location information?
In theory yes but it would mean abstracting a native function and writing new JavaScript that routes around the request for the user's location so it wouldn't be a true test and arguably not of any more value then no tests.
To avoid a profile, if possible we could do one of the following: 1) stub the native browser JavaScript function navigator.getCurrentLocation so that it does something else 2) Automate the clicking of the share current location confirmation message (we do this for confirm dialogues - not sure if possible for share location dialogs..)
On Tue, Mar 18, 2014 at 3:11 PM, Chris McMahon cmcmahon@wikimedia.org wrote:
On Tue, Mar 18, 2014 at 2:22 PM, Jon Robson jrobson@wikimedia.org wrote:
Usually the things that break are simply loading it in the first place which can really only be tested with a browser test.
Can "loading it in the first place" be tested without having to maintain a custom profile for Firefox that overrides default settings for access to browser location information?
On Tue, Mar 18, 2014 at 3:25 PM, Jon Robson jrobson@wikimedia.org wrote:
- Automate the clicking of the share current location confirmation
message (we do this for confirm dialogues - not sure if possible for share location dialogs..)
This sounds promising. And browser-agnostic also.
How does this confirmation appear?
-C
On 03/18/2014 11:46 AM, Chris McMahon wrote:
I guess I thought it was redundant because of the line in url_module.rb ""#{mediawiki_url}#{name}?useformat=mobile"" accomplishes the same thing. Although maybe you need the cookie if you follow a link out to a new URL? Just guessing.
Yes, that's the case.
On Tue, Mar 18, 2014 at 7:36 PM, Jon Robson jrobson@wikimedia.org wrote:
Setting the cookie mf_useformat ensures that the mobile site gets loaded. If tests are run against en.m. etc.. this won't have any effect, but a lot of local instances are setup to run the desktop URL by default. An alternative way of doing this would be to toggle to the mobile site explicitly in the test suite.
e.g. Given /^I am in the mobile view$/ do on(ArticlePage).switch_to_mobile_element.click end
In terms of 2nd question - no I don't think we should abandon trying to test Nearby in the browser, it is one of our most important features and has extremely inadequate test coverage and is one of the things that seems to break the most. Even if the test only works for Firefox, having that test is a good thing.
Chris and I have paired on this. We have left setting the cookie in the mobile fronted repository[1] but we have removed the code for starting a browser with custom profile, needed for nearby tests. The code was deleted because we were able to set the custom profile only on a local machine, meaning the test was not running on jenkins machine. If you want to run this test on jenkins, then we have to figure a way to make the custom profile work with remote browsers.
If you have any questions, let me know.
Željko -- 1: https://gerrit.wikimedia.org/r/#/c/119271/11/tests/browser/features/support/...
On Thu, Mar 20, 2014 at 8:25 AM, Željko Filipin zfilipin@wikimedia.orgwrote:
Chris and I have paired on this. We have left setting the cookie in the mobile fronted repository[1] but we have removed the code for starting a browser with custom profile, needed for nearby tests. The code was deleted because we were able to set the custom profile only on a local machine,
Actually, it didn't even work on a local machine. This was an old spike that Jeff and I never did complete. I filed a bug for us to do this properly at some point: https://bugzilla.wikimedia.org/show_bug.cgi?id=62839