Cleverstack’s End-to-end test on a headless machine

posted in: uncategorized | 0

This is just a article to explain the process that was followed to be able to run end to end tests for Cleverstack from a headless “production like” environment.

This is the scenario: We have 2 virtual machines (can be actual servers). The first machine is a headless instance of Ubuntu 14.04 and we rigged it with an installation like this (click here). The second machine we rigged with an installation of Protractor, as explained here. As per the documentation of Cleverstack, end to end test are run from one environment, but we need to be able to run e2e test on code that is situated on a light weight Linux production server, thus there is no GUI for Chrome etc to be executed in and so the tests will fail. The solution to this is, run the e2e test on the the headless machine, but point the tests to another protractor test machine that launches the browser and so and so forth, whilst still testing the actual production code.

To achieve this, we did the following:

  1. In the ‘Gruntfile’ of the code that is on the headless machine, under ‘appConfig’ declaration, change the ‘hostname’ under the ‘dev’ section from 127.0.0.1 to 0.0.0.0. This makes the Angular frontend accessible from anywhere. The section of the ‘Gruntfile’ should look like this:
    ....
    
    var appConfig = {
    
        // Development Server
        "dev": {
          "port": "9000", // default 9000
          "path": "./app", // the development directory of your app
          "liveReloadPort": "35729", // default 35729
          "hostname": "0.0.0.0" // using 0.0.0.0 will make the server accessible from anywhere
        },
    
        // Unit Testing Server
        "test": {
          "unit": {
            "port": "9090", // default 9090
            "path": "./test", // if you change this it must reflect in your test-unit.conf.js
            "coverage": {
              "port": "5555", // default 5555
              "path": "./test/coverage/" // browsable directory for unit testing code coverage reports
            },
    
    ....
  2. Next, we need to edit the ‘test-e2e.conf.js’ file. Change the ‘seleniumAddress’ field to point to the server that’s running the Protractor instance. The seleniumAddress can look something like this:
    ....
    
      // The location of the selenium standalone server .jar file.
      // http://docs.seleniumhq.org/download/
      //seleniumServerJar: './scripts/selenium-server-standalone-2.39.0.jar',
      // The port to start the selenium server on, or null if the server should
      // find its own unused port.
      //seleniumPort: 4444,
      // https://npmjs.org/package/protractor
      seleniumAddress: 'http://196.192.24.112:4444/wd/hub',
      // Chromedriver location is used to help the selenium standalone server
      // find chromedriver. This will be passed to the selenium jar as
      // the system property webdriver.chrome.driver. If null, selenium will
      // attempt to find chromedriver using PATH.
      //chromeDriver: './scripts/Chromedriver.exe',
      // Additional command line options to pass to selenium. For example,
      // if you need to change the browser timeout, use
      // seleniumArgs: ['-browserTimeout=60'],
    
    ....
  3. Now, if you run ‘clever test e2e’ on the headless machine from the command line, the chrome browser will open on the other server, point back to the production server, run its e2e test on the source code of the production server and you will see the results of the e2e tests in the command of the headless machine.

The process is awesome, yet I think there is still room for improvement and refinement.

 

Leave a Reply