Jump to content

Account creation user experience/Testing/Experiment

From mediawiki.org
Also see Extension:E3 Experiments/Testing
This describes testing for the experiment that modified "Create account" for new users of English Wikipedia by adding JavaScript code to Extension:E3Experiments that modified the page appearance and behavior. The experiment has been running since late in 2012.

The full test query string

[edit]
?title=Special:UserLogin&type=signup&acux_active=1&acux_on=1&acux_eligible=1&acux_debug=1&acux_bucket=acux_3

use acux_bucket=control_3 to see the unmodified form. This will force the page regardless of schedule and even if you're logged in.

To watch bucketing happen, clear userbuckets and clicktrackingDebug cookies, log out, and visit 

?title=Special:UserLogin&type=signup&acux_active=1&acux_on=1&acux_eligible=1

to force the experiment on and eligibility

Append

  • &acux_bucket=acux_3 or control_3 to force bucketing (the number increases each time we change the presentation of the form)
  • &acux_debug=1 to see console output
  • &debug=1 to make MW send the JS separately. Only this mode will report JS errors on the console, so try both ways.

Upon form error, the form is redisplayed without these, so you lose eligibility dates, etc. — all reasons you'll see the form in the old style.

  • You can always enter mw.e3.acux.modifyPage() in a JS console to restyle the page.
  • You can add &campaign=TEST to the query string, see campaign section

Campaign testing

[edit]

ACUX version 4 added support for campaign tracking, initially for the AFTv4 "create an account" Call To Action. If the query string contains campaign=Something, ACUX

  • always shows the fancy acux_N form
  • adds XXXX COMPLETE to userbuckets but ?? doesn't add ACUX bucket.
  • remembers the campaign in its form so that on error the user still sees t


Testing account creation variations

[edit]

A registered user doesn't ordinarily create an account (she has one!), but can navigate to the form and then

  • can create account [By e-mail] (unstyled button)
  • is prompted for Reason (not part of design)
  • may see a checkbox to override AntiSpoof (not part of design)

sometimes

  • may be asked for Real name (not part of design)

For all of these

  • Test if an anonymous user creating her account can see any of these, we have a bug
  • Test weird edge cases when you log out but don't clear cookies, or vice-versa.

Testing username validation

[edit]

See Account creation user experience/Testing/Usernames page for more usernames info

Situation Test username Desired behavior Status
# in username Any# Client-side invalid validation succeeds. MW has 'usernamehasherror' => 'Username cannot contain hash characters' , but it's unused?
# at start of username #Any Client-side invalid x
/ in username Any/ Client-side invalid
Username already exists Is there a guaranteed username? Client-side invalid ✔
leading/trailing whitespace       Any     ??
lowercase first letter, username already exists admin, maybe? sysop? Client-side validation should fail Error from server on submit
Reserved usernames ScriptImporter $wgReservedUsernames
Username like existing (AntiSpoof) Swalling (vs. Swailing on en-wiki) Client-side validation should fail Error from server on submit
Other special characters Hello@There Reject characters in $wgInvalidUsernameCharacters (default is just '@')
Illegal username & password combinations elsewhere (/Engineering ?) invalid after submit (client-side validation deferred) ✔

Other

  • test length (existing form behavior, should be unchanged)
  • test int'l characters , may mess up length restrictions
  • valid username PHP code fails on "invalid due to empty, IP, slash, length, or lowercase"

Testing password validation

[edit]

Not implemented yet

  • test length (existing form behavior, should be unchanged)
  • username & password combos (see above)
  • minimum password length
  • password strength? (deferred? en-wiki allows 1-character passwords)

Testing server API validation

[edit]

Currently only the username is validated on the server before submit

  • Client timeout (suspend browser?)
  • Server timeout (simulate with break in JS debugger?)
  • Slow link (change api/ApiAccountCreation.php to sleep( rand( 1, 3 ); before returning

Automated testing

[edit]

PHP unit testing

[edit]

The e3acuxvalidate API has some tests. Once you have set up PHPUnit: 

$ ../../tests/phpunit/phpunit.php tests/phpunit/api/ApiAccountCreationTests.php

if you set the environment variable MW_INSTALL_PATH. you can also run 

$ cd tests/phpunit
$ make

JavaScript unit testing

[edit]

If you set $wgEnableJavaScriptTest = true; in LocalSettings.php, you can run Special:JavaScriptTest/qunit Current test/ subdirectory is not set up for qunit.

Browser testing

[edit]

Most automated browser testing uses the Selenium web driver to drive a special version of the browser. QA has developed Cucumber-Watir-RSpec tests for the MediaWiki Userlogin that could be extended to account creation.

Meanwhile https://github.com/atdt/karaga is E3Experiments' own Python test framework for making simple assertions ("JavaScript modules loaded without errors", "there should be a cookie", etc.) about browser pages running on https://saucelabs.com.

You can also manually fire up a browser on http://www.browserstack.com/ and look for JavaScript errors while filling out the form.

Retrieved from "https://www.mediawiki.org/w/index.php?title=Account_creation_user_experience/Testing/Experiment&oldid=6415511"