989368 - Write marionette js tests for services/fxaccounts

Status: RESOLVED WONTFIX

(Firefox :: Firefox Accounts, defect, P3)

Description

[Richard Pappalardo [:rpapa][:rpappalardo]]

Create marionette js test(s) for /test_apps/uitest (API/fxa)

Comment 1

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

Thanks for working on this, Richard.  Please be sure to include forceAuth in your tests.
Cheers,
j

Comment 3

[Richard Pappalardo [:rpapa][:rpappalardo]]

(In reply to Jed Parsons (use needinfo, please) [:jedp, :jparsons] from comment #1)
> Thanks for working on this, Richard.  Please be sure to include forceAuth in
> your tests.
> Cheers,
> j

Jed, the (first) 'smoke' tests I've written do a first path with a new user (includes COPPA) and a second pass with an existing user.  by forceAuth, do you mean include a logout, log back in?

Comment 4

[Richard Pappalardo [:rpapa][:rpappalardo]]

Notes from spenrose:
Here are some needs, in what feels to me like order of importance:

1. Integration/acceptance tests for Settings/FTU (IAC API) and one consumer of the RP API 
* Find My Device, the UITest/API/Firefox Accounts mozID screen, or TBD. 
* These should be quite thorough, though they don't need to be quite thorough right away.

2. A "pretty good" (or better) smoke test for both of the above that can be kicked off from the shell, so that developers can work efficiently: edit code, kick off smoke test, walk over to coffee pot and refill cup, return to look at screen and evaluate their change via the smoke test's STDOUT. You just did this with make fxa-test, which is awesome.

3. Thorough coverage of the server API: 
* does the client handle every documented behavior from the server?

4. An excellent example RP API consumer. This may not fall under Q/A per se.

5. Figure out the server endpoint for tests. Do we run against prod, stage, ... ?

------
In my mind, that leads to the following tasks:

1. Build out user story-based automated test cases of the Settings/FTU GUI as far as is practicable. 
* Can we cover all the acceptance criteria?

2. Modify or extract the current UITest code to cover more functionality, adding automation as we go. 
* The code should be a model for new RPs.

3. Continue expanding make fxa-test to run both of previous.

4. Maybe add some automation of Find My Device. 
* In theory, it shouldn't do anything that 2) doesn't, but we want to help them not break even if we think our API is working.

5. Look at adding complete server API coverage, with a focus on errors.
  i. Add unit tests to https://github.com/mozilla/gecko-dev/blob/master/services/fxaccounts/tests/xpcshell/test_client.js 
     that span the server state space.
  ii. Define the contract between services/fxaccounts/FxAccountsClient.jsm (HTTP) and FxAccounts.jsm in the same directory 
      (local state, consumes HTTP results), also spanning the complete state space.
  iii. Define the contract between Gecko and Gaia. 
       What errors will Gecko send to Gaia? Gecko should collapse the state space into a few broad categories 
       (authorization failure, server error, offline, etc.)

The last task is probably mine; the second might be.