Last modified: 2014-10-19 17:44:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T73635, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 71635 - QA: implement "login to <PAGE>" to speed up browser tests
QA: implement "login to <PAGE>" to speed up browser tests
Status: NEW
Product: Wikimedia
Classification: Unclassified
Quality Assurance (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: performance
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-04 05:06 UTC by spage
Modified: 2014-10-19 17:44 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description spage 2014-10-04 05:06:08 UTC
Many tests follow "I am logged in" with "visit FlowPage", "I navigate to Upload Wizard", "I visit the User page of Selenium_user2", etc.  In these cases Special:UserLogin's default behavior of loading the Main_Page upon successful login is a waste of precious time.

MediaWiki has already solved this for human beings. Clients can pass ?returnto=Some_wiki_page to Special:UserLogin so that upon successful login the user is redirected to Some_wiki_page.  It's what the _Log in_ link on every wiki page does, as you can see if you hover over it and note its URL.

For example, http://en.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin?returnto=Talk:Flow_QA

We could expose this as
   Given I am logged in to <PAGE>
in tests.  mediawiki_selenium/step_definitions/login_steps.rb would need to recognize the presence of this optional parameter and append ?returnto=URLEncode(pageName) to LoginPage

I would prototype this but I don't know where the visit() function is defined or documented in our webdriver-selenium-watir-cheezy-cucumber stack.

Is using 
  on(APIPage).client.log_in(ENV["MEDIAWIKI_USER"], ENV["MEDIAWIKI_PASSWORD"])
another alternative?
Comment 1 spage 2014-10-04 06:04:38 UTC
(In reply to spage from comment #0)
> Is using 
>   on(APIPage).client.log_in(ENV["MEDIAWIKI_USER"], ENV["MEDIAWIKI_PASSWORD"])
> another alternative?

This doesn't work.  The mediawiki_api module issues its own HTTP requests from Ruby. So the cookies it gets back aren't set in the browser under test, it only uses them in subsequent API calls. You'd have to tell the browser to make the API POST, or "push" the cookies from the API response into the WebDriver session.
Comment 2 Dan Duvall 2014-10-06 21:36:58 UTC
(In reply to spage from comment #1)
> (In reply to spage from comment #0)
> > Is using 
> >   on(APIPage).client.log_in(ENV["MEDIAWIKI_USER"], ENV["MEDIAWIKI_PASSWORD"])
> > another alternative?
> 
> This doesn't work.  The mediawiki_api module issues its own HTTP requests
> from Ruby. So the cookies it gets back aren't set in the browser under test,
> it only uses them in subsequent API calls. You'd have to tell the browser to
> make the API POST, or "push" the cookies from the API response into the
> WebDriver session.

Passing the cookies over from an API call is an interesting idea, assuming API sessions work in the same way interactive ones do. Of course, this should only be using in setup context (i.e. `Given`) but it would greatly reduce the overhead and fragility of tests that assume a logged-in state.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links