...
When the mobile worker syncs, each case in the payload will have that many copies. So if the loadtest factor is set to 20, and there are the mobile worker has 5 cases to be synced, then a total of 100 cases will be sent to the mobile worker's their device. Loadtest users will get a full restore; all their cases will be sent to their device.
Copies are not created on CommCare HQ, so they will not appear in reports or exports.
Cases to be synced
When a mobile worker syncs their device, not all their cases are in the payload sent to the device: HQ only sends the cases that are not already on the device, or that need to be updated.
So to send loadtest cases to the device, they need to be added on HQ. This can be done using App Preview or Web Apps, or by importing cases from Excel. (Similarly, to sync loadtest cases in App Preview or Web Apps, they need to be added on a mobile device or imported.)
- Register new cases as the mobile worker using App Preview or Web Apps, or import cases from Excel with the mobile worker set as the owner.
- Set the mobile worker's loadtest factor.
- Sync the mobile worker's device
WARNING: If the loadtest cases include case updates, syncing will fail with an error: "Server provided improperly formatted data, please try again or contact your supervisor" (Mobile) or "Could not sync user data. Please report an issue if this persists." (App Preview). This is because loadtest cases need to be new cases, not case updates. To resolve the error, set "loadtest factor" to 1 and sync the case updatesAlthough it is difficult to cause invalid data by interacting with loadtest cases, it is possible. To prevent this, when a mobile worker's loadtest factor is set to a value greater than 1, they are automatically marked as a "demo user". This means that any forms that they submit, or changes that they make to cases, will be ignored by CommCare HQ.
When you view a loadtest user, CommCare HQ will notify you of this:
If you set the user's loadtest factor back to 1 (or delete its value), then the user will no longer be marked as a demo user.
About loadtest cases
Copies will be named with a number after the case name indicating what copy it is. For example, if the original case is named "My Case", then the first copy will be named "My Case (1)", the second copy "My Case (2)", etc.
...
Loadtest cases preserve parent/child relationships: If "Child Case" is the child case of "Parent Case", then "Child Case (1)" will be the child case of "Parent Case (1)", etc. In other words, loadtest case indexes point to other loadtest cases, not to real cases.
Modifying loadtest cases
CommCare allows the user to modify a loadtest case, but CommCare HQ will not create that case.
...
cases
...
Deleting a loadtest case will have no effect on HQ. However, if CommCare HQ creates the same loadtest case again, Web Apps and CommCare Mobile will throw an error when the user tries to sync, and syncing will fail.
Real cases related to loadtest cases
CommCare allows the user to create a real child case whose parent is a loadtest case. It does not allow a user to create a real extension case whose host case is a loadtest case, but it does allow a user to create an extension case whose host case is the child of a loadtest case.All of these scenarios will result in silently broken case indexes in CommCare HQ.
Best practice: Use a temporary mobile worker
...
There are some important caveats about this feature:
...
- This feature does not allow you to test sync performance at scale; it is only for load testing the app.
- Once the sync payload is generated, the user's loadtest factor is reset. This is a safeguard against performance issues.
- The maximum total number of cases that will be synced is 50,000 (unless the user has more than 50,000 real cases). Beyond 50,000 cases, is capped at 500,000. By that point app load will be less important than other aspects of user experience. This is also a safeguard against performance issues.
...