Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Developer Advocate
Developer Advocate

This blog is part of the larger series on all new developer features in SAP HANA SPS 09:

Unit testing and test driven development have increasingly become more popular in the industry in general and specifically within the SAP customer base.  To meet this demand, SAP introduces both an Unit Test framework and a table/view Mock framework in SPS 09.  Its important to note that this test framework is not automatically installed into SPS 09 however. The delivery unit for this framework is delivered as non-automatic content. This means its sitting on the file system of your HANA system and must be imported by an administrator. This is done because we assume customers will want these tools in their development systems probably not production systems.  Therefore we allow you, the customer, to decide if you want the tools installed.

Contents of the HANA_TEST_TOOLS Delivery Unit

  1. XSUnit a unit test framework based on Jasmine, which is a open source JavaScript Test Framework. With XSUnit you can test both JavaScript code and database content. Various extensions have been made to the standard Jasmine library to make it easier to test database content. (unit.jasminexs)
  2. XSUnit Test Coverage for XS JavaScript (unit.codecoverage)
  3. Test Isolation Framework, namely Mockstar, which allows you to test a view or a stored procedure in isolation. (mockstar)
  4. The results of the XSUnit can be persisted in the Test Result Logger
  5. Test Helper (unit.util)
  6. Developer Documentation (doc)
  7. Demos which are a good starting point for how to test various HANA content. (demo)

How to create an XSUnit Test

First of all there is one common tool for testing XS JavaScript and database content such as SQLScript and Views.  It is all based upon the open source libraries detailed in the above section; several of which have been extended by custom assertions and test utilities specific to the HANA environment.

Test code and test data are developed beside your productive code in the same HANA instance as just another XSJSLIB development object.  Test themselves are implemented in XSJS syntax in SAP HANA Studio or the Web-based Development Workbench.

The Unit tests can than be ran standalone in the Web browser via the URL:

Where package = the repository package your test are located within.

These unit tests can also be ran directly from the SAP Web-based Development Workbench.

This has the advantage of displaying the code coverage directly within the editor of the SAP Web-based Development Workbench.

Code coverage can also be displayed in the standalone web tool as well:

By integrating the JavaScript line code coverage library BlanketJS into the XSUnit Test framework, it’s now possible to see, to which extent the JavaScript code is covered (percentage, line based) by the executed test run.

Note that all .xsjslib files which match pattern parameter (default “*Test”) are excluded per default.

Example 1: The coverage is measured for each imported .xsjslib file

Example 2: The coverage is measured for each .xsjslib file located in the mockstar package

Example 3: If you would like to exclude test helpers located in the tests package you can specify them via the “exclude” parameter

However the test tool can also be ran as a service call.  This way if you like to execute the test on a regular basis or trigger by code changes you can use Jenkins as a continuous integration server.  The unit tests are called remotely from Jenkins and the results are stored and displayed within Jenkins. This is a process that we use internally at SAP.


To write self-contained unit tests that are executable in any system, you have to test the HANA model in an isolated way.

An HANA View for example has typically dependencies to other HANA Views or to database tables. These dependencies pass data to the “View under test" and cannot be controlled and overwritten by the test. This means you need the possibility to mock dependencies of the “View under test".

The Mocking Framework, namely Mockstar helps you to test your models with specific test data that resides in dedicated test tables.

Therefore it creates you a copy of your origin view/procedure where the dependent views/tables are replaced by test tables.

These (temporary) tables can be prepared, controlled and filled by the test.

The advantages of mocking are:

  • Write self-contained unit tests that are executable in any system
  • Tests can be executed by several users in parallel