Tuesday, 17 December 2013

Unit Testing Sencha Touch (or ExtJS) applications using Karma Test Runner, Jasmine, Maven and Jenkins


I wanted to be able to run the unit tests for my Sencha Touch 2.3 application locally as well as being able to run them in my continous integration process using Jenkins.

I decides to  use "Karma - Spectacular Test Runner for JavaScript" because it nicely integrates with Jasmine and offers headless execution using PhantomJS out of the box. If PhantomJS is not enough for you, you can also specify other Browsers.

Karma runs on NodeJS. I am not going to describe how to set it up. This information can be found on the Karma site.

Run the tests locally

Here is the 'karma.config.js' I use for local testing.

I bootstrap the Sencha Touch app using the 'development.js' microloader. Because the microloader is loading all required files dynamically I need to specify a proxy element in the Karma config pointing to a local webserver hosting the development version of the application JS files as well as the Sencha Touch JS files.


module.exports = function (config) {
    config.set({
        // base path, that will be used to resolve files and exclude
        basePath: '',

        // frameworks to use
        frameworks: [ 'jasmine' ],

        // list of files / patterns to load in the browser
        // Files for Sencha Touch development microloader
        files: [
            'src/main/webapp/.sencha/app/microloader/development.js',
            'src/test/javascript/setUp.js',
            'src/test/javascript/**/*.js' 
        ],

        // list of files to exclude
        exclude: [
        ],

        proxies: {
            '/': 'http://localhost:8080/'
        },

        // test results reporter to use
        // possible values: 'dots', 'progress', 'junit', 'growl', 'coverage'
        reporters: [ 'progress'],

        // web server port
        port: 9876,

        // enable / disable colors in the output (reporters and logs)
        colors: true,

        // level of logging
        // possible values: config.LOG_DISABLE || config.LOG_ERROR ||
        // config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
        logLevel: config.LOG_DEBUG,

        // enable / disable watching file and executing tests whenever any file
        // changes
        autoWatch: true,

        // Start these browsers, currently available:
        // - Chrome
        // - ChromeCanary
        // - Firefox
        // - Opera (has to be installed with `npm install karma-opera-launcher`)
        // - Safari (only Mac; has to be installed with `npm install
        // karma-safari-launcher`)
        // - PhantomJS
        // - IE (only Windows; has to be installed with `npm install
        // karma-ie-launcher`)
        browsers: [ 'PhantomJS' ],

        // If browser does not capture in given timeout [ms], kill it
        captureTimeout: 60000,

        // Continuous Integration mode
        // if true, it capture browsers, run tests and exit
        singleRun: false
    });
};

If you do not want to use the 'development.js' microloader to bootstrap Sencha Touch one can also point to the single JS file created by a Sencha Command test or production build. Then one does not need the proxy configuration.


        // Files for Sencha Touch test build
        files: [
            'src/main/webapp/build/testing/mae/app.js',
            'src/test/javascript/setUp.js',
            'src/test/javascript/**/*.js'
        ],

The advantage of the 'development.js' microloader approach is that you can changes your JS files and test them immediately. The drawback is that you need a web server running.

The advantage of pointing to the result of a Sencha Command build is that you do not need to have a webserver running. The drawback is that you need to rebuild after every change to your JS files to be able to test them.

You have probably noticed the file 'setup.js' that I include before the real test files.

1) This creates an element in the DOM which Sencha Touch expects
2) Delays the start of the tests till the Sencha Application is ready


// We need to add an element with the ID 'appLoadingIndicator' because [app.js].launch() is expecting it and tries to remove it
var myDiv = document.createElement("div");
myDiv.setAttribute("id", "appLoadingIndicator");
document.getElementsByTagName("body")[0].appendChild(myDiv);

// Karma normally starts the tests right after all files specified in 'karma.config.js' have been loaded
// We only want the tests to start after Sencha Touch/ExtJS has bootstrapped the application.
// 1. We temporary override the '__karma__.loaded' function
// 2. When Ext is ready we call the '__karma__.loaded' function manually
var karmaLoadedFunction = window.__karma__.loaded;
window.__karma__.loaded = function () {};

Ext.onReady(function () {
    console.info("Starting Tests ...");
    window.__karma__.loaded = karmaLoadedFunction;
    window.__karma__.loaded();
});

Another nice thing about Karma is that there is integration into the Webstorm IDE, i.e. you can run and even debug you tests from within Webstorm

Run the tests on Jenkins

I am using a different 'karma.config.js' for running tests within Jenkins.

It uses a "junitReporter" and has "singleRun=true" specified. It loads the "app.js" file  created by Sencha Command containing the Sencha Touch and my application JS files.


module.exports = function(config) {
 config.set({

  // base path, that will be used to resolve files and exclude
  basePath : '',

  // frameworks to use
  frameworks : [ 'jasmine' ],

  // list of files / patterns to load in the browser
  files : [ 'javascript/app.js','javascript/setUp.js',
    'javascript/**/*.js' ],

  // list of files to exclude
  exclude : [ 
  ],

  // test results reporter to use
  // possible values: 'dots', 'progress', 'junit', 'growl', 'coverage'
  reporters : [ 'dots', 'junit' ],

  junitReporter : {
   outputFile : 'karma-test-results.xml'
  },

  // web server port
  port : 9876,

  // enable / disable colors in the output (reporters and logs)
  colors : true,

  // level of logging
  // possible values: config.LOG_DISABLE || config.LOG_ERROR ||
  // config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
  logLevel : config.LOG_INFO,

  // enable / disable watching file and executing tests whenever any file
  // changes
  autoWatch : false,

  // Start these browsers, currently available:
  // - Chrome
  // - ChromeCanary
  // - Firefox
  // - Opera (has to be installed with `npm install karma-opera-launcher`)
  // - Safari (only Mac; has to be installed with `npm install
  // karma-safari-launcher`)
  // - PhantomJS
  // - IE (only Windows; has to be installed with `npm install
  // karma-ie-launcher`)
  browsers : [ 'PhantomJS' ],

  // If browser does not capture in given timeout [ms], kill it
  captureTimeout : 60000,

  // Continuous Integration mode
  // if true, it capture browsers, run tests and exit
  singleRun : true
 });
};

I am using Maven to build my app:

1) Sencha Command builds the app.js in the 'generate-resources' phase
2) I specify where my "test resources" are so Maven can copy them to the target folder
3) In the "test" phase Karma runs the tests.

Here is a snippet from my POM:


<build>
 <!-- Specify the location of the test resources and JS files -->
 <testResources>
  <testResource>
   <directory>${basedir}/src/test/resources</directory>
  </testResource>
  <testResource>
   <directory>${basedir}/src/main/webapp/build/${senchaBuildEnvironment}/mae</directory>
   <includes>
    <include>app.js</include>
   </includes>
   <targetPath>javascript</targetPath>
  </testResource>
  <testResource>
   <directory>${basedir}/src/test/javascript</directory>
   <targetPath>javascript</targetPath>
  </testResource>
 </testResources>
 <plugins>
  <!-- Sencha Command will build our web-application -->
  <plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>exec-maven-plugin</artifactId>
   <version>1.2.1</version>
   <executions>
    <execution>
     <id>SenchaCommand</id>
     <phase>generate-resources</phase>
     <goals>
      <goal>exec</goal>
     </goals>
     <configuration>
      <workingDirectory>${basedir}/src/main/webapp</workingDirectory>
      <executable>/sencha/Cmd/4.0.0.203/sencha</executable>
      <arguments>
       <argument>app</argument>
       <argument>build</argument>
       <argument>${senchaBuildEnvironment}</argument>
      </arguments>
     </configuration>
    </execution>
  <!-- Karma runs the JS tests in the 'test' phase -->       
    <execution>
     <id>Karma Test Runner</id>
     <phase>test</phase>
     <goals>
      <goal>exec</goal>
     </goals>
     <configuration>
      <workingDirectory>${basedir}/target/test-classes</workingDirectory>
      <executable>node</executable>
      <arguments>
       <argument>${node.modules.home}/karma/bin/karma</argument>
       <argument>start</argument>
      </arguments>
     </configuration>
    </execution>
   </executions>
  </plugin>
  ...

I have different profiles for test and production builds, .e.g.
     
<profile>
 <id>production</id>
 <activation>
  <property>
   <name>env</name>
   <value>production</value>
  </property>
 </activation>
 <properties>
  <senchabuildenvironment>production</senchabuildenvironment>
 </properties>
</profile>

Now Jenkins simply calls "mvn -Denv=production clean test".

I configured Jenkings to pick up the "karma-test-results.xml" file to display the test results:

**/target/surefire-reports/*.xml, **/target/test-classes/karma-test-results.xml

Tuesday, 3 December 2013

Sencha Touch 2 production builds and delta updates


A production build by Sencha Cmd (sencha app build production) will create a minfied version of your application. 

It uses a microloader (embedded in index.html) which caches the JavaScript (e.g. app.js) and CSS (e.g. app.css) files specified in “app.json” into the Browser's local storage (using a hash of the file content to identify the “version” of the file).
 
This enables the micoloader on further loads of the application to only download the app.json file, because this file contains the information which versions of the JS and CSS files need to be loaded.

If the JS and CSS files have not changed they can be read from local storage. If a file has changed it will have a different “version”-hash in app.json. The action then taken by the Microloader depends on the value of the “update” attribute associated with the respective file:
·         "update": "delta"
o   A delta-file with the changes is downloaded by the microloader and patched into the file stored in local storage
·         "update": "full"
o   The file will be loaded via Ajax call and stored in local storage


How delta-updates work



Archive Folder:
·         During a production build Sencha Cmd copies each file into the “build/archive”-folder
·         Each file goes into a folder named like the file; the file itself will be named like the hash of its content
·        Therefore the “archive”-folder contains the history of all the versions of all the files which have been built in any production build, e.g.
o   archive\app.js\     <<<  The folder named like the file
-  88c900a6530d892d21fbae08670c074e727c35ba  <<< 1st built
-  28688b22ae4da508dc6deb3e6e90473ee525d1c1 <<< 2nd built
-  727eebf10074ef70fd1584c3ced713b610197094  <<< current built
Deltas-Folder:
·         Sencha Cmd creates a “deltas”-folder for the web application (build/[appName]/production/deltas)
·         For each of the previously built files (stored in the archive folder) a delta-json-file (compared to the current file) is created, e.g.
o   deltas\
-  88c900a6530d892d21fbae08670c074e727c35ba.json
-  28688b22ae4da508dc6deb3e6e90473ee525d1c1.json
-  Each of these files contains the delta to the current file: “727eebf10074…”
·         When the Microloader loads “app.json” it sees that the version “727eebf10074…” is the current version of “app.js”
·         Depending on the version stored in local storage it loads the correct delta file, patches the stored file and stores it in local storage with the updated version number ”727eebf10074…”