our original todo list, to be broken down

[rjbs]

For each datatype - that you can create:

• with every field you're allowed to specify specified
• with only the minimum specified. (in both cases, that the values are returned as specified in a get, or with updates as expected by the spec)
• that the created message ids appear in a getFoosUpdate.
• if there's a relationship (i.e. parentId) possible, that you can create a few items, in a tree, with backreferences and they all create correctly in the same tree
• for fields with constraints (including datatypes), that a create which fails those constraints is rejected
• for each field that is required, that a create which is missing that field is rejected (I guess that's just constraints, right)

For update:

• that you can reference created things again (create a folder, move existing messages into it)
• all the constraints stuff above, trying to move things in a way that fails constraints
• attempting to modify any immutable field fails.
• updating a non-existent message gives a sane notUpdated response

For delete:

• deleting a non-existent message gives a sane notUpdated response
• you can't delete anything by ID that's still referenced as a parentId / mailboxId / whatever by another piece of data.
• normal delete is fine

For any of the above - make sure they appear in getFoosUpdates between pre and post states.

For container types (Mailboxes, Calendars, Addressbooks) that adding something to the container causes the container to get a new state, updates to the container to show it, and deleting also shows - with a special emphasis on something being deleted entirely causing the state to change and the result to reflect it. This is the QRESYNC side of things - tombstones, and it's one of the most likely sources of bugs.

Ideally a smart test would allow getFoosUpdates to return cannotCalculateUpdates and just flag as "inefficient server but within spec". Calculating updates incorrectly on the other hand, that's a sin. Also a server which returns more updates than expected isn't necessarily wrong - but probably worth noting in the results as "inefficient server" or something.