Testing

PWA Testing

To test the PWA (Progressive Web App), build the app for PWA testing and run the server without ng serve. From the repo root

cd src/SIL.XForge.Scripture/ClientApp/
ng build --configuration=pwaTest
cd ..
dotnet run --start-ng-serve=no

!!! IMPORTANT !!! When you have finished testing, remove the built app dist folder. From the repo root

rm -rf src/SIL.XForge.Scripture/ClientApp/dist

Physical Device Testing

To test localhost on a physical device you need to ensure you have the following:

• An Android device
• The latest version of Chrome on your desktop
• The latest version of Chrome on your device
• USB debugging enabled on your device

Enabling USB debugging first involves switching on developer mode on your device. This usually involves going to your System->About screen and tapping repeatedly on your build number. Doing a Google search for, "How to enable USB Debugging on {device name}" should help get it enabled. Once the device is developer mode there will be a new developer link on your device - likely under system - and in there you'll find an option to toggle on USB debugging.

With USB debugging turned on navigate in Chrome on your desktop to chrome://inspect/#devices. Your device may at this point present a prompt to allow your Chrome browser access to debug your device - you must allow this. Once allowed your device name will appear in the list of available devices. Before you can run the app you first need to update the Port forwarding settings to reflect our app. Click the button on the inspection screen and set as follows:

• 5000    |    localhost:5000
• 5003    |    localhost:5003

You're now ready to go. Build the app as normal on your desktop using dotnet run or ng serve or whichever variation you need. Once the build is complete, open up Chrome on your device and navigate to localhost:5000. On your desktop the inspection page will show all the open tabs you have in Chrome on the device. Locate the tab running http://localhost:5000/ and click the inspect link. A new window will open with the Chrome DevTools giving you full access to the console, DOM, network, screen sharing, etc.

Please note that if your device goes to sleep or switches to the lock screen then the USB debugging will no longer have permission.

Offline testing

When locally testing Scripture Forge, you can simulate being offline. A simple way to do so would be to stop the backend dotnet application, which will also stop the realtime server.

Alternatively, you can pause operation of the realtime server, and then resume it, by sending SIGSTOP and SIGCONT. Interestingly, this does not make the broken cloud icon to appear in the frontend, but in the backend you may see instances of "Jering.Javascript.NodeJS.InvocationException: The Node invocation timed out after 60000ms".

pkill --parent $(pgrep SIL.XForge.Scri) --full 'node -e module.exports' --signal SIGSTOP
pkill --parent $(pgrep SIL.XForge.Scri) --full 'node -e module.exports' --signal SIGCONT

Tokens

During testing, it can be useful if your refreshToken is not valid. You can invalidate your user's refreshToken in MongoDB by manually sending a refresh request.

To do this, use a tool to send a POST to https://registry-dev.paratext.org/api8/token with headers Content-Type and Accept set to "application/json" and with a body of the following, where client_id and client_secret are SF site-specific, and refresh_token is your current refreshToken from the user_secrets collection in mongodb.

{
  "grant_type": "refresh_token",
  "client_id": "--",
  "client_secret": "--",
  "refresh_token": "--"
}

For example, with curl:

curl --location --request POST 'https://registry-dev.paratext.org/api8/token' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data-raw '{
    "grant_type": "refresh_token",
    "client_id": "--",
    "client_secret": "--",
    "refresh_token": "--"
  }'

What you receive back is the new refresh_token, and so the one in MongoDB is no longer valid. It may help to also erase the access token from MongoDB with something like the following, since the access token may not have expired yet.

const sfUserId = "put_user_sf_id_here";
const userSecretsCollection = db.collection("user_secrets");
let userSecret = (await userSecretsCollection.findOne({ _id: sfUserId }))!;
console.log("before", userSecret);
await userSecretsCollection.updateOne({ _id: sfUserId }, { $set: { "paratextTokens.accessToken": null } });
userSecret = (await userSecretsCollection.findOne({ _id: sfUserId }))!;
console.log("after", userSecret);

You might also just erase the paratextTokens.refreshToken if it's not significant that it exist but be rejected.