Functional test architecture
The Cadasta Functional Test Suite is a separate project that provides automated user-interface tests to verify the functionality of the Cadasta Platform from the point of view of a user using a web browser. The test suite uses Selenium as the main technology for writing automated tests. These tests are written in Python using Selenium bindings. Selenium, in cooperation with the browser software companies, provides various WebDrivers that interface with a real browser like Firefox or Chrome, or a headless browser like PhantomJS. The tests instruct the WebDriver which then controls user interactions on the browser such as entering text into form fields or clicking buttons.
Shown below is the generic architecture of a Selenium test. The test instructs the WebDriver what to do and the WebDriver controls the browser, which interacts with a web server.
For local testing on the development VM, the architecture generally follows the generic pattern described above and as shown below. We can either use the Chromium (Chrome) browser with the ChromeDriver or the Firefox browser with the GeckoDriver.
For functional test builds using Travis CI, there are two options: local testing or using BrowserStack. The first option is just like local testing on the development VM as shown below. Again, we can have the choice of using either Chromium or Firefox as the browser with their corresponding WebDrivers.
The second option allows us to use many different browsers on many different operating systems via BrowserStack, with which Cadasta has a subscription account. In this setup, the platform web server is running inside a Travis VM. Because this server is not public, in order to allow browsers on BrowserStack to access the server, we make use of the BrowserStack Local proxy, which Travis already provides as an option.
See the BrowserStack documentation on BrowserStack Local and the Travis CI documentation on enabling BrowserStack Local for more information.
In the future, it is possible to perform functional testing directly on the platform server running in a test production environment such as the staging server. The diagram below shows how this can be configured. The only major change is that instead of specifying the server URL as localhost:8000 or 0.0.0.0:8000, we specify the public-facing URL of the server (such as staging.cadasta.org) when executing the functional test.
