Deployment And Auto Run

As others we applications, the project should be stored in a remote repository and deployed to a remote server. So that the team can colabourate on the test project. The remote server can perform auto-testing periodically, and even join the appication CI/CD pipeline.

Push the test project to VCS repository

The handow-seed project is an opensource project on Github. You just need adjust it a little bit, e.g., change the project name, and push the project to your own repository. That's it, the team can work on the project now.

Deploy the test server to cloud

Normally, the test server is installed to a cloud VM and continue updated with target application developing. It is recommended to implement your application CI/CD solution to deploy the E2E project. As a reference, here it is how to deploy it manually on the Ubuntu VM. Assumin we have prepared to deploy the Handow E2E project:

• A VM (e.g., Ubuntu 18.04 LTS instance) is available.
• The Node.js has been installed to the machine.
• Git has been installed to the machine, and the project has been stored located in a Git repository.

Install more libraries to Ubuntu

The Handow engine depends on Playwright which provides browser APIs for Chromium, Firefox and Webkit. We need to install browser related libraries because they are not included in standard Ubuntu image.

Install libraries for Chromium:

$ sudo apt update
# Install libs supporting Chromium (need more libs required for firefox or webkit)
$ sudo apt-get install gconf-service libasound2 libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0 libgtk-3-0 libnspr4 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 ca-certificates fonts-liberation libappindicator1 libnss3 lsb-release xdg-utils wget libgbm-dev

Clone and install the project

Assuming the test server, e.g. myUAT is going to install to /opt/apps/ directory.

/opt/apps $ git clone [.../myUAT]

Install dependencies.

/opt/apps/myUAT/ $ sudo npm install

Verify it by manually startup. The test server will listen port 3333, make sure it is enabled in current VM.

/opt/apps/myUAT $ sudo npm start

Then you can access http://[IP Address]:3333/ with any browser to verify the SHM server.

The Handow test server depends on file system as data store. sudo command is required to get full permission.

Run the test server as daemon service

The systemd can manage the test server as a daemon auto running in background. We just need add a service unit file, e.g. 'myUAT.service', to /usr/lib/systemd/system/:

# /usr/lib/systemd/system/myUAT.service
[Unit]
Description=My UAT server basing on Handow solution

[Service]
PIDFile=/tmp/myUAT.pid
Type=simple
# me - the valid username
User=me
WorkingDirectory=/opt/apps/myUAT
# ExecStart=/usr/bin/sudo /usr/bin/node node_modules/handow-shm/launch.js --public --3333
ExecStart=/usr/bin/sudo /usr/bin/node node_modules/handow-shm/launch.js --secure --3333
# ExecStart=/usr/bin/sudo /usr/bin/node node_modules/handow-shmlaunch.js --private --3400

[Install]
WantedBy=multi-user.target

Start the service manually (or restart the VM).

$ sudo systemctl daemon-reload
$ sudo systemctl start handowuat

Done, you can access the SHM server with URL _http://[IP Address]:3333/.

Update the test application manually

When the test project is updated, e.g., added more test cases or changed the plan, etc., you need update the project in VM.

/opt/apps/myUAT/ $ git pull
/opt/apps/myUAT/ $ sudo systemctl restart myUAT

Others

The SHM server can run in public|secure|private modes basing on 2 roles: admin|user. The admin role users get full permission to access the SHM server and test resources. The user role users just have Read-Only permission to browse test reports and some test resources.

• public mode - Visitors are assigned admin role automatically, no sign-in required.
• secure mode - Visitors are assigned user role automatically, the admin users need to sign in to access protected resources and operations.
• private mode - Visitors cannot access SHM server unless sign in as admin or user

You can choose the running mode of the SHM server in cloud, mostly it should be secure or private. After the serser is deployed, you need login with admin role to setup up users. The original admin credential is "admin | admin" which has been added in handow-seed. Users need to add new users with differen role and set the credentials. The admin-user can access Setting dashboard to change user profiles.

Auto run

You can use Run button to run a specific plan or story when the SHM server is deployed in you local machine in developing. But that's not they way for remote test server. The SHM instance deployed in cloud VM always run test plans on schedule or on demand (even it possible to run plans manually). The admin can set the auto-run mode with Setting dashboard.

Infinite loop

If this mode is selected, the specific plans will run again and again infinitely. It's not recommended unless you have some special requirements.

Timer schedule

Specify plan groups with starting time, so these plans will run automatically on daily base.

Http trigger

The test server will listen to a http call, and then run the plans specified in the http request.

Related documents

• Design Test Plan
• SHM Setting