Under the hood: Call flows

It can be helpful to look at the application’s call flows to understand the inner workings. For a casual user, this is, of course, not necessary. Nevertheless, I created this blog post for users who wants to know what goes on “under the hood” of Boozang. 

We will look at two different use-cases. The first case is when a user is working in the IDE, creating and modifying tests. The second one when a user is running tests using a CI server.

The project dashboard (in the Cloud)

The user must first be authorized to do any work in the IDE. The authorization happens via the Cloud instance login page.

• Americas (Montreal): https://ai.boozang.com
• Europe (Frankfurt): https://eu.boozang.com

After entering the login and password, the user will see the projects that he/she has access to and can create new ones. 

We are still in the Cloud in this view, and nothing is loaded on the client-side. 

Working in the IDE

As soon as the user wants to do any real work, he/she needs to launch a project. Typically, a user will only work on a single project at a time, and any existing open IDE project session will be terminated when creating a new one. 

After launching the project “The Cucumber Lab”, the user will be presented with a novel browser window: The Boozang IDE

Things have now changed: The user is now working locally in his browser, where the application IDE is loaded client-side. As soon as the user does a change, such as creating, updating, or deleting a test, the difference is synchronized via a web socket connection with the Cloud (either ai.boozang.com or eu.booang.com). As web sockets are a bi-directional (full-duplex) communication protocol, we can now synchronize this change across all other clients.

For example, if team member Anna and team member Adam is both working on Test A, they will see any changes made in real-time. This is often a great collaboration feature, similar to Google docs, but can also be undesired. In the cases where this is undesired, the team members should be working on different branches (see blog post on Branching and Merging: /enterprise-boozang-aligning-tests-with-code-branches/).

The call flow can be seen below

Running a test on the CI server.

After you have created your tests and organized them into test suites, you typically want to run them in a CI server. As Boozang is completely browser-based, there are many ways to do this. The easiest way is probably to use the Docker container boozang-runner, which is Open Source and can be found here

https://github.com/ljunggren/bz-docker-xvfb

The Boozang runner utilizes Puppeteer to control the Chrome browser and Xvfb to support headless runs. The Chrome browser’s built-in headless mode does not support running any Chrome extensions, so we have found that running Chrome in real mode with a virtual frame buffer is preferred. 

To run a test on a CI server such as Jenkins, you need to have Docker installed. To run a test you simply need to type in the test URL, like

BASE=http://ai.boozang.com
TOKEN=c3c3c3c3c3c3c3c33c3secret
ENV=0
PROJECT=60c94425994507096855aa53
BRANCH=master
SELF=0
TEST=m2/t1
GROUP=
SCOPE=
PARAMETER=
WORKERS=1

MASTER_URL="${BASE}/extension?parameter=${PARAMETER}&token=${TOKEN}${PROJECT}&group=${GROUP}&scope=${SCOPE}&env=${ENV}&key=1&self=${SELF}#${PROJECT}/${BRANCH}/${TEST}/run"
docker run --rm -v "$(pwd):/var/boozang/" --name=bzworker1 styrman/boozang-runner "${MASTER_URL}"

As you can see, there are many parameters to set, but most of them are to facilitate parallel test runs. You can generate all this config from the CI screen in the IDE interface (see below).

As you can see, each user has a personal token. It’s sometimes desirable to create a specific user CI user with its unique user token.

Below you can see the call flow for when a CI test is being run.

Conclusion

Going into depth like this around the inner working of an application is sometimes a little overkill. On the other hand, by going into details, it becomes more apparent to the end-user why a feature was built in a certain way and will help them troubleshoot the application easier. 

We also believe that the specific way Boozang was architectured is a great case for using it. By running a lightweight client that does all the testing instead of driving tests from the Cloud, we can avoid scalability issues. An additional benefit is also that there is no need to open any company firewalls, thus reducing the pain of adoption and potential security issues.