I ran an audit of the existing browser tests for MobileFrontend as
part of a mobile team spike [1]. You can see the results here:
https://www.mediawiki.org/wiki/Mobile/QA_Test_Audit_March_2014
Our coverage is actually not too bad, but there is definitely room
from improvement. That said I have a big concern is around the
organisation of the tests and how they are written and what is written
- many of the tests could do with being reworded and a lot of them
should probably actually be deleted. There is a lot of code
duplication.
When auditing I found tests scattered all over the place. This
suggests that we could benefit from reorganising the file structure to
be more logical, in particular features that relate to special pages
should have their own folder (this is particularly useful for
clarifying what tests the watch star and what tests the actual
watchlist page - Zeljko / Chris is it possible to have subfolders in
the features directory that contain features?).
I would also suggest the following actions for improving our test coverage:
* Add tests for error handling on login / account creation
* Add tests for this page has issues
* Improve tests for key editing and upload workflows
* Add tests for Language variant support
* Add tests for full text search support
* Improve the existing watch star tests so they actually check the end result
* Add test to check the user can close the left navigation menu
* Add tests for logout
* Add tests for reference overlay
* Add tests for toggling
* Add tests for Nearby in skins other than Minerva (mobile skin)
* Address hygiene issues on
https://www.mediawiki.org/wiki/Mobile/QA_Test_Audit_March_2014
[1] https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1687
Hello!
We are getting closer to a general release of the Wikipedia Android
and iOS apps, and I think we should standardize on a User-Agent
format. The old app just appended an identifier in front of the
phone's default UA[1] but I think we can do better, to avoid privacy
concerns[2].
How about:
WikipediaApp/<version> <OS>/<form-factor>/<version>
This gives us all the info we need (App version, OS, Form Factor
(Tablet / Phone) and OS version) without giving away too much. It is
also fairly simple to construct and parse.
For the latest alpha, my Nexus 4 would generate
WikipediaApp/32 Android/Phone/4.4
While an iOS device might generate
WkipediaApp/2.0 iOS/Phone/7.1
form-factor would just be Phone|Tablet for now, and can be expanded
later if necessary.
Thoughts?
[1]: https://www.mediawiki.org/wiki/Mobile/User_agents#Apps
[2]: https://www.mediawiki.org/wiki/EventLogging/UserAgentSanitization
--
Yuvi Panda T
http://yuvi.in/blog
Heads up that Shahyar from the Flow team met up with Juliusz and I to
discuss better code sharing and thus easier integration betwen Flow
and MobileFrontend. It seems we are doing various things in a similar
fashion and there is an opportunity to share code.
You can see Shahyar's notes below but the main areas that could do
with immediate consolidation are as follows:
* Both use client side templates but with different template
libraries. MobileFrontend has a method of serving these via
ResourceLoader. We recommended that we consolidate this code asap and
aim to push it into core, rather than have the situation where we are
both using our own code. We should make this template agnostic to fit
in with the ongoing RFC around client side templates. I cut a story
card to try and get this on MobileFrontend's radar -
https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1800
* Flow uses jquery microsize to auto expand a textarea when typing,
mobile has its own lightweight library to do this.
* Both Flow and MobileFrontend use a lightweight library to generate
user friendly last modified timestamps ( e.g. 3 days ago etc) - this
is much smaller than moment.js in core
* Both extensions use Class inheritance JavaScript model.
---------- Forwarded message ----------
From: Shahyar Ghobadpour <sghobadpour(a)wikimedia.org>
Date: Tue, Mar 25, 2014 at 2:34 PM
Subject: Mobile & Core Features front-end meetup technical notes
To: "Editor engagement list for the core E2 development team."
<e2(a)lists.wikimedia.org>
Cc: Juliusz Gonera <jgonera(a)wikimedia.org>, Jon Robson
<jrobson(a)wikimedia.org>, Tomasz Finc <tfinc(a)wikimedia.org>
Core Features met up with the front-end guys from Mobile, and we, in
Maryana's words, creeped on each others' code. This gave us a lot of
insight into how our teams have been doing things (spoiler alert: it's
very similar).
Here are my notes, from Flow's perspective on things:
Classes
Can extend objects
Call parents with .super
Notable classes:
EventEmitter
Binds events to objects, but is in fact just a wrapper for jQuery.Events
Overlay
M
Uses M.require to grab a constructor/class
Not big, just basically to make sure that the loading order is correct
and all requested modules actually exist
New ones added via M.define
Templates
Hogan
methods:
preRender
postRender
Most useful; adds logic to templates after the fact
Currently, they use this to find elements and bind (events) directly to them
mw.template implements template compiling, getting, adding
mw.template.add is called by resourceloader
Currently uses Hogan only, but could easily be changed to use
Handlebars (could even just overload mw.template.compile)
History State Management
Currently only implements hash change event
Android 2.3 and Android 4.0 do not correctly (how?) support history
API for adding more URLs to the history
Currently still in flux due to various issues
Would be worth combining efforts to make a better one
API
mw.api sucks, they wrote their own
Each API is subclassed
eg. editorApi implements its own special methods on top of Api
CSS
Has separate responsive styles for tablet and for phone
In individual files and loaded when needed, so as to not slow down the
base CSS with too many media queries
Might change; they may end up getting concatenated later on for simplicity
At 768px adjustment begins for media queries (to be standardized
between Mobile and Flow)
Misc
Custom micro.autosize.js
Automatically resizes textareas as you type
Only 600 bytes unminified
--Shahyar
The Page Object design pattern divides browser tests into three areas: the
controller, where the test is created (this is a description of the test):
the steps of the test, which are actions taken by the test (the steps are
verbs, actions, navigation from one place to another and checking on
status; and the page definitions, which are the nouns against which the
steps/actions/verbs are working.
In our implementation of the Page Object pattern:
* the Cucumber feature files are the story of the tests
* the steps.rb files are the verbs and actions
* the page.rb files are the nouns and the pages
If you know anything about Design Patterns, you may know that they are
discovered, not invented. Among people who do browser testing, the Page
Object design pattern is generally accepted to be the best known solution
for creating browser tests that are robust, readable, maintainable, and
that will scale to large numbers of tests.
In practice, that boils down to some rules that we need to follow, and one
of those rules is: *no element identifiers in steps files*. Page elements
like div and span that have identifiers of e.g. class: and css: need to be
managed in the page.rb files and *only* in the page.rb files.
Do not put page element identifiers into the steps of the test. This makes
the tests difficult to read, difficult to scale, and very difficult to
maintain.
Adhere to the Page Object design pattern: keep your page element
identifiers in the /support/pages/*page.rb files ONLY, and NOT in the
/step_definitions/*steps.rb files.
http://en.m.wikipedia.beta.wmflabs.org/ has been giving me a 503 all
morning. I really need to be able to use it since we are deploying a change
this week that is specifically related to the cluster configuration
(specifically overriding the licensing messaging to support dual licensing
for the WMF projects).
Bug filed:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63315
Ryan Kaldari
We introduced a pre-review hook in mobile that makes it hard for you
to submit new code when there is existing code to review (check out
[1] if you are interested)
The problem I find is it tells _me_ to do code review, but all the
patches belong to me so I can't review them. I can poke people and ask
them to review it, but this usually isn't fruitful as it results in
"I'll do that later" or "I'm busy right now".
I feel that the pre-review hook is making me aware of other people's
patches more often but I've had to force override it a few times like
just now when I've found that I own all the existing patches (as I'm
scared I'll lose the patch or forget about the patch otherwise). This
actually has had the effect on me of investing time in other projects
like data analysis, mailing list discussions, coding on VectorBeta,
Limn and core rather than concentrating my energy on MobileFrontend. I
also feel reluctant to pick up new cards to work on when I'm in this
limbo state as I don't want to overwhelm the code review queue or end
up managing various patches that might conflict with each other.
I feel like I've contributed less to the MobileFrontend project as a
result - not sure if this is a good or a bad thing. That said it is
certainly a frustrating thing for me as I want to work on it more...
Something to think about.
[1] http://git.wikimedia.org/blob/mediawiki%2Fextensions%2FMobileFrontend/f7320…
We are considering changing the colours in the diff page view for mobile.
Previously Vibha and Munaf had explored this (see results below). Have we
run similar tests for the new colours on the diff page?
---------- Forwarded message ----------
From: Munaf Assaf <massaf(a)wikimedia.org>
Date: Thu, Mar 28, 2013 at 3:21 PM
Subject: Diff views for the colorblind
To: Jon Robson <jrobson(a)wikimedia.org>
Cc: Vibha Bamba <vbamba(a)wikimedia.org>, Maryana Pinchuk <
mpinchuk(a)wikimedia.org>
Vibha and I tested these settings out and they work pretty well.
[image: Inline image 1]
Threads are getting split here, but attempting to reach the sites via IP
does not appear to work either, at least for me and presumably for Kaldari
as well.
On Mon, Mar 31, 2014 at 11:52 AM, John <phoenixoverride(a)gmail.com> wrote:
> Probably a local DNS issue. Since the move the associated IP addresses
> changed
>
> On Mon, Mar 31, 2014 at 2:43 PM, Arthur Richards <arichards(a)wikimedia.org
> >wrote:
>
> > +wikitech-l/qa
> >
> > I presume this is a byproduct of the migration. This is urgent.
> >
> >
> > On Mon, Mar 31, 2014 at 11:25 AM, Ryan Kaldari <rkaldari(a)wikimedia.org
> > >wrote:
> >
> > > http://en.m.wikipedia.beta.wmflabs.org/ has been giving me a 503 all
> > > morning. I really need to be able to use it since we are deploying a
> > change
> > > this week that is specifically related to the cluster configuration
> > > (specifically overriding the licensing messaging to support dual
> > licensing
> > > for the WMF projects).
> > >
> > > Bug filed:
> > > https://bugzilla.wikimedia.org/show_bug.cgi?id=63315
> > >
> > > Ryan Kaldari
> > >
> > > _______________________________________________
> > > Mobile-l mailing list
> > > Mobile-l(a)lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/mobile-l
> > >
> > >
> >
> >
> > --
> > Arthur Richards
> > Software Engineer, Mobile
> > [[User:Awjrichards]]
> > IRC: awjr
> > +1-415-839-6885 x6687
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
Kenan,
Need you to take action on a couple of trello columns [1] to close our sprint 27
= Ready for sign off =
* 2 stories waiting
** Design refinements for the left nav menu
** As a logged out editor of the app I want to be warned about IP
editing and get the chance to login before I save my edit
= Doing =
* Table of Contents - should we carry it over to spring 28?
= ToDo =
* Which bugs should be moved over?
--tomasz
https://trello.com/b/qb2lPChs/mobile-app-sprint-27-navigation