Appium 2.0 is now officially released.
Sauce Labs supports Appium 2.0

Does Lambda Test support Appium 2.0?

https://appium.io/docs/en/2.0/guides/migrating-1-to-2/#overview-of-appium-20

This will help determine if skipped tests in Sauce Labs are because of us being behind. It may also solve other test issues that have been difficult to figure out, like getting page source on iPad iOS 14 devices.

Both BC Wallet CANdy(Connectionless) and BCID tests are failing in the Nightly regression testing, Can't fix these locally until a workaround is in place for issue 645

AS AN AMTH Test Developer, I WANT to use an iOS Simulator on my local machine with my locally setup AMTH, SO THAT I can debug the tests in my local IDE.

As of build 575 the app pushed to Sauce Labs is set to the Prod environment. The settings/Developer mode is used to switch to Test. Until this is implemented all Credential issuance and Proof test will fail in the nightly regression cycle.

Attempt get element by partial accessibility id or text

AS A AMTH user, I WANT to be able to give multiple issuers and/or verifiers on the run command, SO THAT so that tests written with specific issuers and verifiers can run at the same time as other tests.

Right now, there is a BC wallet test T009-Proof where it uses the CANdy Unverified Person Issuer and a PCFT Chat Demo Verifier. This is a specific test for connectionless presentations. If running with the AATH issuer and verifier, one needs to exclude this from the test run with the -t ~@T009-Proof option.

It might be nice to pass in multiple issuers or verifiers on the command-line or passing a config file or something and let the tests determine and use the agents it needs to run the test.

Workaround:
Separate run commands locally and in GHAs specifically for different agents. Along with maybe a separate Allure report project for the differing configurations.

AS A Tester of an Aries Mobile Wallet, I WANT the Issuer/Verifier AATH aca-py agents AMTH stands up uses to use the same varied ledgers that the wallet under test is using, SO THAT the wallet and agents can have successful communications

At this time AATH uses a Ledger URL, this may not be available and would need to use a GENESIS FILE or GENESIS URL.

https://app.zenhub.com/workspaces/bc-wallet-6148e7423fe04b001444e2bd/issues/bcgov/bc-wallet-mobile/412

The above ticket is closed and manually tested but the acceptance criteria need to be automated in the automated regression tests in the Offline Handling test suite.

iOS or Android in page objects, locators etc, can be different. Can we have a a dictionary for accessors for iOS and Android and based on the device use the appropriate one? Or do we need a library of methods to call based on the device?
Can use the device that is passed into page objects on the context object to make accessor/locator decisions.

It has been requested that the dev team for the React Native app use the AccessibilityLabel/AccessibilityID as the unique identifier for app elements. This should allow us to use the same locator across platforms. This still has to be tried in the real works, but the risk is low that it will not work.
We still may have to use different locator methods between iOS and Android. So may still need a dictionary of methods for that.

AS A AMTH user with a private test repo and wallet app, I WANT to be able to use my own Issuer and/or Verifier interfaces with AMTH without having to modify the the public agent factory in AMTH, SO THAT our internal details of our agents remain private.

ACCEPTANCE CRITERIA
Given a AMTH User with Private Issuer and Verifier Agents
And they have implemented AMTH agent interfaces for these Agents
| issuer_agent | verifier_agent |
| MyPrivateIssuerAgentInterface | MyPrivateVerifierAgentInterface |
When I run a script to modify the agents json file to add my agent interfaces
And I copy my agent interfaces into the AMTH structure
And I run AMTH with the -i "MyPrivateIssuer;<myprivateissuer endpoint>" -v "MyPrivateVerifier;<myprivateverifier endpoint>"
Then AMTH will run my wallet tests with my Agent interfaces

One possible way to accomplish this is to use a plugin architecture in Python utilizing importLib.

TL;DR 🏎️

Teams are encouraged to favour modern inclusive phrasing both in their communication as well as in any source checked into their repositories. You'll find a table at the end of this text with preferred phrasing to socialize with your team.

Words Matter

We're aligning our development community to favour inclusive phrasing for common technical expressions. There is a table below that outlines the phrases that are being retired along with the preferred alternatives.

During your team scrum, technical meetings, documentation, the code you write, etc. use the inclusive phrasing from the table below. That's it - it really is that easy.

For the curious mind, the Public Service Agency (PSA) has published a guide describing how Words Matter in our daily communication. Its an insightful read and a good reminder to be curious and open minded.

What about the master branch?

The word "master" is not inherently bad or non-inclusive. For example people get a masters degree; become a master of their craft; or master a skill. It's generally when the word "master" is used along side the word "slave" that it becomes non-inclusive.

Some teams choose to use the word main for the default branch of a repo as opposed to the more commonly used master branch. While it's not required or recommended, your team is empowered to do what works for them. If you do rename the master branch consider using main so that we have consistency among the repos within our organization.

Preferred Phrasing

Pro Tip 🤓

This list is not comprehensive. If you're aware of other outdated nomenclature please create an issue (PR preferred) with your suggestion.

TL;DR

Topics greatly improve the discoverability of repos; please add the short code from the table below to the topics of your repo so that ministries can use GitHub's search to find out what repos belong to them and other visitors can find useful content (and reuse it!).

Why Topic

In short order we'll add our 800th repo. This large number clearly demonstrates the success of using GitHub and our Open Source initiative. This huge success means it's critical that we work to make our content as discoverable as possible. Through discoverability, we promote code reuse across a large decentralized organization like the Government of British Columbia as well as allow ministries to find the repos they own.

What to do

Below is a table of abbreviation a.k.a short codes for each ministry; they're the ones used in all @gov.bc.ca email addresses. Please add the short codes of the ministry or organization that "owns" this repo as a topic.

That's it, you're done!!!

How to use

Once topics are added, you can use them in GitHub's search. For example, enter something like org:bcgov topic:citz to find all the repos that belong to Citizens' Services. You can refine this search by adding key words specific to a subject you're interested in. To learn more about searching through repos check out GitHub's doc on searching.

Pro Tip 🤓

• If your org is not in the list below, or the table contains errors, please create an issue here.

• While you're doing this, add additional topics that would help someone searching for "something". These can be the language used javascript or R; something like opendata or data for data only repos; or any other key words that are useful.

• Add a meaningful description to your repo. This is hugely valuable to people looking through our repositories.

• If your application is live, add the production URL.

Ministry Short Codes

NOTE See an error or omission? Please create an issue here to get it remedied.

We may need the ability to have extra appium capabilities set at the scenario level. There are cases arising where having the biometrics turned off or on allowTouchIdEnroll=true and the device language set setCapability("language", "en") before driver is instantiated for the scenario.

Maybe a @extra_config_<test_identifier> tag on the scenario in the feature file, and if it is there, we load extra capabilities from a file called <test_identifier>.json located in the features folder. It would do this in the before_scenario() function in the environment.py file before driver is created.

The Appium-Python-Client was locked to version to 3.2.1. 4.0.0 was released on March 11th 2024 and removed touch action support which is used for scrolling in base page objects. Replace that scrolling code and anywhere else that uses touch actions and multi touch actions with W3C actions, which will be compatible with Appium Python Client 4.0.0.

See Migrating from V3 to V4 here, https://pypi.org/project/Appium-Python-Client/4.0.0/

STORY
AS A tester for the BC wallet I WANT to be able to use a local real device to run tests against SO THAT I can debug problems in the device cloud or to do quick testing and verification without having the device cloud involved

Acceptance Criteria:
GIVEN the AMTH is setup and able to execute
WHEN I give the command manage run specifying local and bundelID details of my connected local device
THEN the AMTH will run tests against the connected local device

Subtasks:

• Get Appium Server and Appium inspector running with the local iOS device
• Get Appium Server and Appium inspector running with the local Android device
• Integrate local Android device with AMTH BC Wallet tests
• Can Vysor be used to automate a local connected devices easier than a dev env locally?
• Determine config.json settings for local devices
• Update manage script to allow local as an option

Questions:

1. Should the Manage script start Appium Server locally?
2. Should the manage script build a container for appium server?

• Would only work for Android only. iOS would still need appium installed on mac. iOS also needs Xcode installed. It is best to let the user manage this. (maybe Vysor changes this assumption)

There is a config.json file that tells Sauce Labs/Appium what devices to use, what the Sauce Labs username and access key is, what the app key is to identify it in the cloud, etc. These things should be passed into the manage script and either create a new config.json for every run, or populate an existing config.json.

Question:
Can we have config.json files of different names?

If different names and differing locations are used for config.json files, then we need to create a way to let the tests, environment.py in particular, which config to use.

Manage script should create a config.json and set environment variables before running.

AS AN AMTH Test Developer, I WANT to use an my real iOS device connected to my local machine with AMTH, SO THAT I can run and develop tests utilizing a real device instead of a simulator.

Allow test developers to use a dev container in VS Code so that they do not have to install a test environment locally to develop and debug mobile tests.

How will this work with a locally connected emulator or real device?
Could the container have both the vs code env and an android emulator env?

AS AN AMTH Test Developer, I WANT to use an Android Emulator loaded in a separate test container managed by the test harness, SO THAT I don't have to have an android development environment on my local machine to run tests and I don't need a paid cloud device service.

Possible container to use: https://github.com/appium/appium-docker-android/blob/master/README.md

Due to the decommissioning of https://pctftest-test.vonx.io/ we will need to mimic this scenario on the verifier side with the test verifier agent instead of PCTF Chat.
See details here, bcgov/issuer-kit-demo-verifier-chat#90 (comment)

This impacts test T009-Proof.
Will need to adjust the test verifier to make it a connectionless proof request.
Using the following format for the proof request. https://github.com/esune/essential-services-delivery/blob/master/proof-configurations/verified-person/unverified-person.json

{
  "id": "unverified-person",
  "subject_identifier": "given_names",
  "configuration": {
    "name": "unverified-person",
    "version": "0.0.1",
    "requested_attributes": [
      {
        "name": "given_names",
        "label": "Given Names",
        "restrictions": [
          {
            "schema_name": "unverified_person",
            "schema_version": "0.1.0"
          },
          {
            "schema_name": "unverified_person",
            "schema_version": "0.2.0"
          }
        ]
      },
      {
        "name": "family_name",
        "label": "Family Name",
        "restrictions": [
          {
            "schema_name": "unverified_person",
            "schema_version": "0.1.0"
          },
          {
            "schema_name": "unverified_person",
            "schema_version": "0.2.0"
          }
        ]
      },
      {
        "name": "birthdate",
        "label": "Date of Birth",
        "restrictions": [
          {
            "schema_name": "unverified_person",
            "schema_version": "0.1.0"
          },
          {
            "schema_name": "unverified_person",
            "schema_version": "0.2.0"
          }
        ]
      },
      {
        "name": "street_address",
        "label": "Street Address",
        "restrictions": [
          {
            "schema_name": "unverified_person",
            "schema_version": "0.1.0"
          },
          {
            "schema_name": "unverified_person",
            "schema_version": "0.2.0"
          }
        ]
      },
      {
        "name": "postal_code",
        "label": "Postal Code",
        "restrictions": [
          {
            "schema_name": "unverified_person",
            "schema_version": "0.1.0"
          },
          {
            "schema_name": "unverified_person",
            "schema_version": "0.2.0"
          }
        ]
      },
      {
        "name": "locality",
        "label": "City",
        "restrictions": [
          {
            "schema_name": "unverified_person",
            "schema_version": "0.1.0"
          },
          {
            "schema_name": "unverified_person",
            "schema_version": "0.2.0"
          }
        ]
      },
      {
        "name": "region",
        "label": "Province",
        "restrictions": [
          {
            "schema_name": "unverified_person",
            "schema_version": "0.1.0"
          },
          {
            "schema_name": "unverified_person",
            "schema_version": "0.2.0"
          }
        ]
      },
      {
        "name": "country",
        "label": "Country",
        "restrictions": [
          {
            "schema_name": "unverified_person",
            "schema_version": "0.1.0"
          },
          {
            "schema_name": "unverified_person",
            "schema_version": "0.2.0"
          }
        ]
      }
    ],
    "requested_predicates": []
  }
}

The Readme file has an Apache2 license badge but does not link to or include the actual license file.

It might be a good enhancement to AMTH to have an option on manage for -logPageSourceOnFailure, or something like that, and then we can add a log/print in the after_scenario() to print out the apps page source on failure.
We could then even add that page source to the allure reports so someone could see it in the failure results when executed in the CI pipeline.

Put iOS and Android app in BrowserStack to try the Camera QR code scanning.
Create some utilities to make sending up the QR code and scanning easier.

./manage build
./mange rebuild
./manage run

I think all properties needs to be passed through the ./manage run command. Sauce Username, Access Key, App Name, region, etc.

Manage Build & Rebuild

Build should build the test harness and retrieve/build the agent(s) needed in the test scenarios for that app.
Rebuild will ignore cache and completely rebuild the image.

./mange build -w bifold -i acapy-main -v acapy-main

-w = Wallet name to use Page Objects for the appropriate app under test to copy into the container.
-i = Issuer Agent. This will be solution dependant. There will need to be a way to build and stand up this agent in the test environment. TBD
-v = Verifier Agent. This will be solution dependant. There will need to be a way to build and stand up this agent in the test environment. TBD

Manage Run

./manage run -d SauceLabs -u oauth-sheldon.regular-32de4 -k 4dba5e58-16c0-4532-b43e-4a543701610d ~-r api.us-west-1~ -p iOS -a bifold-bc.zip -i acapy-main -v acapy-main -t @Feature1 -t ~@T003

-d = Device Cloud to use. This will create configs for this particular Device Cloud. SauceLabs is supported, and BrowserStack is supported.
-u = Device Cloud username
-k = Device Cloud Access Key
-r = if SauceLabs is used, you will need a region. Currently api.us-west-1
-p = Device Platform (iOS or Android) If left out assume both running in GRID.
-a = iOS or Android App Identifier of the app already in the Device Cloud
-i = Issuer Agent
-v = Verifier Agent
-t = Only run tests with/without these tags
-r = Generate official Allure Reporting in this test run. It does not upload to the Allure Server. That is done by a separate script that runs in CI.

env vars should be set for ALLURE_SERVER, ALLURE_PROJECT and REGION (when Sauce Labs is used) instead of having these as passed in to the test harness options. If ALLURE_PROJECT is not set then use the APP_NAME for the project.

Outstanding Questions

• How do we let the harness know what devices to run on?
• How do we tell the harness to run on both android and iOS for this run?
• How do we let the harness know we want to run tests in Parallel?
• Should the harness try to upload the app to the cloud or assume it is there? I think we assume it is there, but we need to pass in the app identifier for the config. What if it is iOS and Android? Use -aa and -ia, if both are used then we can run in parallel or one after the other.

Example: https://github.com/hyperledger-labs/solang/blob/main/MAINTAINERS.md Example of a pointer: https://github.com/hyperledger-labs/homebrew-solang/blob/main/MAINTAINERS.md

Developers using ARM based MACs commonly run into issues using the AMTH scripts. The underlying reason is that there are no ARM based base images for several of the projects and services used by AMTH, such as von-network. The permanent solution would be to update the base image builds to include support for the ARM architecture. Unfortunately in some cases this is tricky as the dependencies for the images don't all support the ARM architecture.

The workaround is to tell docker to use amd64 emulation when running on an ARM based MAC. This is done by setting DOCKER_DEFAULT_PLATFORM=linux/amd64.

A script to auto-detect ARM based MACs and set DOCKER_DEFAULT_PLATFORM=linux/amd64 has been added to von-network, apply this workaround to the AMTH scripts. bcgov/von-network#272

There may be a need to handle the reporting of multiple sets of environments in the allure reporting service.

If multiple runs happen within a GitHub Workflow with different configurations, like different issuers or verifiers, and the results are sent to the same projects, the environment.properties will contain the environment from the final run, and not be representative of all the tests executed.

Workaround:
Have separate allure projects for differing configurations and separate the test runs.

BCSC test integration running in the nightly test pipeline needs special consideration when logging into the Pilot crew issuer with a github ID compared to running locally. Logging in with GitHub requires an auth code that is email to the login account. Google api is used to login to the gmail account and get the auth code to enter in the Pilot issuer screen when asked.

Current issue is the json for the google token to authenticate is in a secret, then passed around as an environment variable until the test harness picks it up and uses it. There is an issue with the json as it gets passes around in the environment.

A base page object should already hold members that achieve common things all page objects must do.

There might be one existing on the internet that may already be a good start.

No Project Lifecycle Badge found in your readme!

Hello! I scanned your readme and could not find a project lifecycle badge. A project lifecycle badge will provide contributors to your project as well as other stakeholders (platform services, executive) insight into the lifecycle of your repository.

What is a Project Lifecycle Badge?

It is a simple image that neatly describes your project's stage in its lifecycle. More information can be found in the project lifecycle badges documentation.

What do I need to do?

I suggest you make a PR into your README.md and add a project lifecycle badge near the top where it is easy for your users to pick it up :). Once it is merged feel free to close this issue. I will not open up a new one :)

This can wait until we have tests to run continually.

We can use the same configuration as the Allure service we have for AATH Interop Testing.

• Standup an Allure server. Use the Allure Docker Service.
• updating manage script to take an allure option to output to allure
• A script to upload results to allure.
• Can we download the video of the test and add to allure?

Hello guys,
I am having a new Mac M1 apple Silicon , (configuration -MacOs Ventura-13.2.1 (22D68)).
I am using Docker Desktop (Version-4.18.0)
Using Rosetta 2 in terminal.

Here is My run commands..
1. sh copy_tests_to_test_harness.sh
2. cd aries-mobile-test-harness
3. (./manage build -w nb_wallet )
4. LEDGER_URL_CONFIG=http://test.bcovrin.vonx.io REGION=us-west-1 ./manage run -d LocalAndroid -p Android -a /Users/amarjeetverma/Downloads/MyApp.apk -v "AATH;http://0.0.0.0:9030" -i "AATH;http://0.0.0.0:9030" -t @nb_wallet -t @T001-connection

I am able to run till 3rd command -- ./manage build -w nb_wallet
When i am running my 4th command- I am getting the issue

Running with Device Cloud Service SauceLabs
Executing tests without Allure Reports.
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
Path to the config file = /aries-mobile-test-harness/aries-mobile-tests/features/../config.json
Starting Chrome on Mac or Windows for Issuer Agent
[WDM] - Downloading: 100%|█████████████████| 6.75M/6.75M [00:00<00:00, 9.86MB/s]
HOOK-ERROR in before_feature: WebDriverException: Message: unknown error: Chrome failed to start: exited abnormally.
(unknown error: DevToolsActivePort file doesn't exist)
(The process started from chrome location /usr/bin/chromium is no longer running, so ChromeDriver is assuming that Chrome has crashed.)
Stacktrace:
#0 0x0040006e6fe3
#1 0x004000425d36
#2 0x00400044eb20
#3 0x00400044aa9b
#4 0x00400048caf7
#5 0x00400048c11f
#6 0x004000483693
#7 0x00400045603a
#8 0x00400045717e
#9 0x0040006a8dbd
#10 0x0040006acc6c
#11 0x0040006b64b0
#12 0x0040006add63
#13 0x004000680c35
#14 0x0040006d1138
#15 0x0040006d12c7
#16 0x0040006df093
#17 0x004002585fa3 start_thread

when I see the logs in container of Docker.. I can see that container starts..but exits in 2-3 secs. and its image of (AMD64) ..

Anyone please help me out to fix it

Questions:

• Can we use the AATH agent backchannel/controller with Traction?
  --This will impact the effort. If the tests have to speak to a different controller then I'd double the effort.

AS A user of AMTH, I WANT to pin the version of the Aries Agent Test Harness in my pipeline, SO THAT I don't break my test execution and I can choose to move up a version when I have calibrated my pipeline to accommodate the changes.

AS AN AMTH Test Developer, I WANT to use an my real android device connected to my local machine with AMTH, SO THAT I can run and develop tests utilizing a real device instead of a simulator.