Skip to content

Testing

Jump to bottom
marksvc edited this page Jun 7, 2023 · 4 revisions

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. Unfortunately, Chromium does not support moving existing websocket connections offline as of 2023-06-07; see bug 423246.

Pause RTS

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) node --signal SIGSTOP
pkill --parent $(pgrep SIL.XForge.Scri) node --signal SIGCONT

Interrupt tunnel

Another way to interrupt the realtime server connection is to connect by a tunnel and interrupt the tunnel. You can do this in Ubuntu by doing the following: Install socat:

sudo apt install socat

Modify src/SIL.XForge.Scripture/ClientApp/src/environments/environment.ts by changing

-  realtimePort: 5003,
+  realtimePort: 15003,

Run socat:

socat tcp6-listen:15003,fork,reuseaddr tcp:[::1]:5003

Press Ctrl+C to kill socat, and interrupt the tunnel to realtime server. The SF frontend will show the broken cloud icon. Re-run socat to bring the connection back up.

Tokens

Paratext Registry (or dev) uses oauth2 to give an access token and a refresh token which SF stores. The access token is a JWT token.

You can fetch your Paratext tokens from the SF DB with the following command after modifying the script to use your email address, or manually looking in mongo.

scripts/db_tools/db-token-info.ts

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 PT Registry.

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, and automatically populating the client_id and client_secret:

REFRESH_TOKEN="put-your-refresh-token-here"
PROJ_DIR="${HOME}/src/web-xforge/src/SIL.XForge.Scripture"
curl --include --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\": \"$(cd "${PROJ_DIR}" && dotnet user-secrets list | perl -n -e 'print if /^Paratext:ClientId/ and s/.* = //')\",
    \"client_secret\": \"$(cd "${PROJ_DIR}" && dotnet user-secrets list | perl -n -e 'print if /^Paratext:ClientSecret/ and s/.* = //')\",
    \"refresh_token\": \"${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.

You can test whether an access token is still valid with curl:

ACCESS_TOKEN="put-your-access-token-here"
curl --location --request GET 'https://registry-dev.paratext.org/api8/userinfo' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --header "Authorization: Bearer ${ACCESS_TOKEN}"
Clone this wiki locally