Skip to main content

Architecture

The Pumpo Number Five testing framework has been built around several strong requirements:

  • Tests must be 100% code but easy to write
  • Test execution must be supported from local machine and from worker nodes of any CI system
  • Complex secure networking setup must be supported
  • Web and Mobile testing must be compatible with publicly available services such as Browserstack
  • Any API endpoints must be supported next to UI testing to allow true end-to-end testing

Deployment architecture

The deployment architecture relies on three tiers:

  1. Test runtime - Can be local machines of testers or any worker node of a CI tool anywhere on internet
  2. Test farm - Where all the client hosts run: browsers, mobile phones, Windows apps, various API clients representing e.g. external systems interacting with systems under test
  3. Systems under tests - May be in a protected environment - Usually test environments are not accessible from internet as production is

On the schema below the test farm is made of one main host and two extensions. The purpose of extensions is to solve the issue with various platforms (Linux / Windows) and the issue with hardware performance when it comes to mobile testing.


Full architecture


Tests provide instructions to components on the test farm that interact with systems under test. The components on the test farm can be of two types:

  • User interface host applications: browsers, mobile applications, Windows applications
  • Various API clients: REST, SOAP, Kafka, SQL, SFTP, IMAP/SMTP, ... and the list is growing as specific needs are encountered by Pumpo#5 adopters

The user interface host applications usually come with a native driver that allows to emulate user interaction based on instructions received. To receive instructions, in the web domain the industry standard is so far the Web Driver protocol.

Pumpo#5 has the unique feature to extend the Web Driver Protocol also to work for any other API. Next to browsers, the test farm has various proxy clients available that listen to Web Driver protocol instructions and realise native calls in the selected API to target systems under test. The component allowing that mapping is called Driver8 and is provided along with the Pumpo#5 library.

Test code framework

Tests are written in Java where Pumpo#5 is a standard Java library. The library focuses on simplifying tests code.

Following are the key features simplifying how tests are written:

  • Most of the page UI objects can be written in a declarative way
  • The builder pattern (fluent interface) is promoted to maximum
  • Initialisation of drivers on the test farm is automated based on simple declarations
  • Each domain has a specific language that has been designed with care to reflect tester's needs

To get an idea of this may look like, let's have the following example:

class TestClass {

@Test
public void sampleTest(
MyWebApplication browser,
MyHttpApplication restClient,
MySqlApplication sqlClient) {

String userName = Generator.generateRandomUserName();

browser.open(HomePage.class)
.clickRegister()
.fillUserName(userName)
.submit();

restClient
.prepareRestRequest("https://example.com/api/activate", "GET")
.withQueryParam("userName", userName)
.sendAndGetResponse()
.assertStatus(200);

int userId = sqlClient
.prepareQuery("select id from users where userName %s")
.withJdbcParams(userName)
.execute()
.rowsAsListOfJsonNodes()
.get(0).asInt();

System.out.println("User registered with id: " + userId);

}

}

Pumpo#5 will automatically initialise a new browser on the test farm as well as Driver8 instances allowing to send REST calls and query an SQL database. The names of those endpoints in the test can be freely chosen. Each endpoint allows specific actions (those will be proposed by the IDE autocomplete) that can be chained in a nice flow that could be understood by more than just the author of the test.

Another challenge when it comes to test coding is how to manage configuration. Pumpo#5 also comes with a concept enabling easily scaling complexity of the configuration.

... details to come soon about that, so far please check the dedicated section Test Configuration