Account creation user experience/Testing/Experiment


 * Also see Extension:E3 Experiments/Testing

The full test query string
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 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. &mdash; 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
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
A registered user doesn't ordinarily create an account (she has one!), but can navigate to the form and then sometimes
 * 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)
 * 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
See ../Usernames page for more usernames info

Other
 * test length (existing form behavior, should be unchanged)
 * test int'l characters, may mess up length restrictions

Testing password validation
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
Currently only the username is validated on the server before submit


 * Client timeout (suspend browser?)
 * Server timeout (simulate with break in JS debugger?)

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

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

Browser testing
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.