Fidelity test accounts

The Google and Microsoft suites act as a person's account: they send mail, make events and upload files. To run them live, you sign a test account in once with danwo fidelity login, and danwo keeps its refresh token in .env.fidelity.

The GitHub suite acts as a GitHub App instead, installed on one sandbox repository. You make the App once, as below.

Offline, nothing is needed. The emulator plays the account, and the goldens come from what Google and Microsoft publish: the Discovery documents for Gmail, Calendar and Drive, and Microsoft Graph's OpenAPI description.

npx @danwo/cli fidelity login google
npx @danwo/cli fidelity google

What the login does复制标题链接

It listens for the redirect on this machine, opens the provider's consent page, and exchanges the code with PKCE. It shows the scopes it asks for before the browser opens:

Signing a Google test account in for the fidelity suites. It is asked for:
  openid
  email
  https://www.googleapis.com/auth/gmail.modify
  https://www.googleapis.com/auth/calendar.events
  https://www.googleapis.com/auth/calendar.calendarlist.readonly
  https://www.googleapis.com/auth/drive.file
The consent page sends the browser back to http://127.0.0.1:8765/callback; the client must register it.
Sign in with a test account, not your own. If the browser does not open, go to:
  https://accounts.google.com/o/oauth2/v2/auth?...
Saved DANWO_FIDELITY_GOOGLE_REFRESH_TOKEN in .env.fidelity for [email protected].
Granted: openid email https://www.googleapis.com/auth/gmail.modify ...
Run the live suite with: danwo fidelity google

The token itself is never printed. Only its line in .env.fidelity changes; the other lines, comments and the file's 600 mode stay as they were.

Make a Google client复制标题链接

1. In the Google Cloud Console, pick a project and enable the Gmail, Calendar and Drive APIs.
2. Under Google Auth Platform → Audience, keep the app in Testing and add your test account as a test user.
3. Under Clients, create a Web application client and register the redirect URI.
4. Put the client in .env.fidelity.

DANWO_FIDELITY_GOOGLE_CLIENT_ID=....apps.googleusercontent.com
DANWO_FIDELITY_GOOGLE_CLIENT_SECRET=...

Make a Microsoft client复制标题链接

1. In the Azure portal, open Microsoft Entra ID → App registrations and register a new app. For a personal test account, allow personal Microsoft accounts.
2. Add a Web platform redirect URI, the one the login uses.
3. Under Certificates & secrets, create a client secret and copy its value.
4. Add the delegated Graph permissions for mail, calendars and files.

DANWO_FIDELITY_MICROSOFT_CLIENT_ID=...
DANWO_FIDELITY_MICROSOFT_CLIENT_SECRET=...
DANWO_FIDELITY_MICROSOFT_TENANT_ID=common

Reuse your app's OAuth client复制标题链接

If your app already signs people in to Google or Microsoft, its client works too. Give danwo one of the redirect URIs it registers, and danwo listens on that URI's host, port and path.

DANWO_FIDELITY_GOOGLE_REDIRECT_URI=http://localhost:3050/settings/integrations/google-verify
DANWO_FIDELITY_MICROSOFT_REDIRECT_URI=http://localhost:3050/settings/integrations/microsoft-verify

Stop your app's dev server first, since the login needs its port. If the port is busy it says so:

danwo fidelity login: port 3050 on localhost is in use: stop the app on :3050 first (its dev server, most likely), then run the sign-in again

The URI must use http on localhost or 127.0.0.1. The client must also allow the scopes the login asks for.

When it fails复制标题链接

Make a GitHub App复制标题链接

The GitHub suite reads public data with only DANWO_FIDELITY_PUBLIC=1. Everything else it checks, such as the check runs and pull request comments danwo's reporter posts, needs a GitHub App on a sandbox repository.

1. Create a private repository for the suite, with one README commit on main. Keep nothing else in it.
2. Under Settings → Developer settings → GitHub Apps, create a new App. Turn Webhook off.
3. Give it the repository permissions below, and no others.
4. Under Private keys, generate a key. Save the .pem file outside your repositories.
5. Choose Install App, pick Only select repositories, and select the sandbox.

The App's id is on its settings page. The installation id is the number at the end of the installation's settings URL. Put them in .env.fidelity with the key's path and the repository:

DANWO_FIDELITY_GITHUB_APP_ID=123456
DANWO_FIDELITY_GITHUB_APP_PRIVATE_KEY_PATH=/Users/you/keys/danwo-fidelity.pem
DANWO_FIDELITY_GITHUB_INSTALLATION_ID=12345678
DANWO_FIDELITY_GITHUB_REPO=you/danwo-fidelity

In place of the path, DANWO_FIDELITY_GITHUB_APP_PRIVATE_KEY can hold the key itself on one line, with its line breaks written as \n. Then run the suite:

npx @danwo/cli fidelity github

github (live): 9 of 9 scenarios match
  ✓ repos: public repository (1 known)
  ✓ errors: unknown repository
  ✓ app: JWT, installation and installation token
  ✓ installation: its repositories and the sandbox repository
  ✓ issues: comment, edit, label and close
  ✓ contents: a branch, a file on it, read back
  ✓ pull request: open, the report comment edited in place, close
  ✓ check runs: in progress, more than 50 annotations, completed
  ✓ errors: missing issue, bad conclusion, a token without access

cleaned up: 15 object(s) undone, nothing left behind

Without all of them, the App scenarios are skipped and the public ones still run.

What a run leaves in the sandbox复制标题链接

Each scenario makes what it needs with a token limited to the sandbox repository, and undoes it when it ends. The token is revoked last.

An App can't delete issues, so closed issues and pull requests titled danwo-fidelity-<run> stay. Check runs stay on the commits of the deleted branches. If a run is cut short, --sweep github --yes closes its open issues and pull requests, and deletes its branches and labels.

Live runs stay in their lane复制标题链接

• Everything a run makes is tagged danwo-fidelity-<run>, and removed after each scenario.
• Mail goes only to the account's own address.
• Untagged mail, events and files are never touched. --sweep lists tagged leftovers.

Next复制标题链接