1st Meeting: GSoC 17 Parallel Testing
Date: 5th May 2017
Time: 07:00 (UTC / GMT) 09:00 (CEST)
Meeting was attended by: Niels Braczek, Tito Alvarez, Astrid Guenther, Andrei Isac
1) Discussed about the overall architecture and most needed features
2) Task selection was discussed in details
3) Virtualization and Execution Queue, some of the topic discussed as part of the next steps
4) Project Scope was discussed, next steps were defined and questions that still need an answer were stated.
1. Discussing the most needed features
Tito Alvarez provided a proposal including all needed features.
Andrei Isac shows a diagram. The Execution List is a list with tests. These tests we will create in different branches of the repo.
All clients (C1 to C8 in the picture) have the same environment (no different browsers or operating systems). But in the future we want to support different environments. We have a pool of clients for all the server environments, so we need to optimize the client execution time while preventing that one server can hijack all the clients.
There will be a Task Selection Algorithm, that will pop a task from the Execution List, every time a Client is available.
Figure 1. Task Selection Algorithm
We need one database container and 8 application layer containers and we need many clients.
The clients can be configurable for every execution, the idea is to load the tests into each client so each client can perform any, in any server environment.
If we have 8 server environments, that means we have 8 execution lists.
So if there are 10 tasks (tests), we will actually perform 80 tasks.
Figure 2. Testing Environment Containers
2. Task selection
Figure 3. Architecture Illustration
Each task can have:
For the start we will use the weblinks tests as tasks. These tasks will continue to expand in the future
Weblinks acceptance tests
Dependencies would only be like this
1 -> 2.1, 2.2, 2.3, 2.x -> 3
This means concretely, that a test of the web link component and the uninstall needs the installation of the component weblinks. But there should not be dependencies between the 2.x tests in the list. So all tests for weblinks should run successful independently.
3. Virtualization and Execution Queue
4) Project Scope and next steps
We have to define
The actual way the task selection algorithm will "pop" the next task - we need one algorithm so select the next available task. This should be flexible, so that we can use different clients (with different browsers) in future.
The structure (up to now the RoboFile - but later a yml, xml or json configuration file) that we will use to define the task list and prerequisites.
How is the server environment selected - we need an algorithm to decide what to do when a client becomes available? Point 1.3 and 1.5 in JoomlaAT architecture.
Main Coordinator and Task Selection
We will divide the areas into individual epics / issues and enter them in our project plan.