Step 1: Overview and Testing Strategy

To set up your project for this tutorial, download the files for Step 1 from the Explored app in the Demo Kit under Testing - Step 1 . Copy the code to your workspace and make sure that the application runs by calling the webapp/test/mockServer.html file.

Depending on your development environment you might have to adjust resource paths and configuration entries. The project structure and the files coming with this tutorial are explained in detail in the Walkthrough tutorial.

You should have the same files as displayed in the following figure:

Figure 2: Folder structure with downloaded files

With the downloaded coding, you have been handed over the bulletin board prototype that is set up according to the SAPUI5 best practices and provides the following common features of an SAPUI5 app. If you have gone through the Walkthrough tutorial, you should be familiar with most of the source code in this step. Additional features of the app are:

• Entry Page

  In this tutorial we will often switch between manually testing application features and running the automated tests. The webapp/test/test.html file provides a list of entry points for the app so that you do not have to enter the URLs manually. From this page you can open the app with mock data, run the unit tests, run the integration tests, or run the app’s test suite that will be added later in the tutorial. Note that in a productive scenario we would have an additional entry point that calls the app with a real service. As we do not (yet) have a real service for our prototype but operate on mock data we simply left this one out.

• Home Page

  The home page of our bulletin board app is the webapp/test/mockServer.html file. On this page, we initialize SAPUI5, start the mock server, and instantiate our app component. It only consists of a single view that displays a list of posts from a bulletin board with several attributes in a table.

  Note

  We do not yet have a real service for the bulletin board prototype so run the app with mock data and this test page throughout the tutorial. The mock server helps in mimicking a real service and it processes requests with a small delay as a real service would do. This is perfect for realistic application testing and also helpful for local development tests. It is also a good practice to put all test pages in the test folder of the app, so that they are clearly separated from the productive coding.

• Data

  In the webapp/localService/ folder, you can find the metadata and the mock data for the app. The metadata.xml file is used by the mock server to simulate real back-end service calls in the app. It describes our OData service and can be replaced later by a real service. The service we use has just one OData entity:

  • Post

    A post consists of typical properties like Title, Description, and Price. Each post is assigned to a Category and a Contact. The entity can be identified with its ID property: PostID. The corresponding EntitySet is Posts. The actual test data containing several mocked posts is located in the webapp/test/service/posts.json file.

• Testing Functionality

  The team that created the first prototype already took care of the basic test setup. Everything required for application testing is shipped with SAPUI5 and can simply be used within the app. The testing infrastructure is set up in the test folder that is located in the webapp folder of the app:

  • Mock Server

    The mock server is set up in the webapp/localService/mockserver.js file. It loads the metadata and the mock data in the same folder. Using the mock server allows us to easily run the app and show realistic data for testing, even without network connection and without the need of having a remote server for our application data.

    There is a configurable delay for each request that is processed by the mock server that allows mimicking a slow back-end server.

  • Unit Tests

    All unit tests are located in the webapp/test/unit folder and can be started by calling the unitTests.qunit.html file in the same folder. Initially, there are only a few tests for model instantiation and formatters that cover basic functionality in the prototype. We will explain more details about the unit test setup later.

  • Integration Tests

    Integration tests are written in OPA5 – a tool for integration testing that is included in SAPUI5 – and can be found in the webapp/test/integration folder. You can start all OPA5 tests by calling the opaTests.qunit.html file in the same folder. OPA5 tests are organized in test journeys, and there is already a worklist journey included that checks if the table of posts is displayed properly. We will explain more details about the integration test setup later.

• Other quality-related features of the app

  The app is set up according to best practices and already contains many helpful features. The most important ones are named here.

  • Separation of concerns (MVC)

    All artifacts are located in either the model, view, or controller folder of the app. The app’s component and its descriptor is configuring which of those MVC artifacts to load. the configuration is controlling the navigation flow of the app.

  • Separation of productive and non-productive code

    All non-productive code is located in the test subfolder. This includes the unit and integration tests, and the test page to call the app with mock data. All productive code is located in the webapp folder. This clearly separates the test artifacts from the application coding and makes it easy to remove all test-related artifacts before deploying the app for productive use.

  • Busy handling

    As a best practice, users should always get instant feedback when triggering actions and navigating in the app. The app already includes functionality to display a busy indication when data is loaded or actions are triggered. To simulate a slow backend and show the behavior of the app the mock server is configured with a delay of one second for each request.

Now we have a running prototype that we can further extend with additional tests and features. Make sure the app is running by calling the test page, the unit tests, and the integration tests from the entry page webapp/test/test.html. The app should display a list of bulletin board posts as seen in the screenshot above and the tests should run without errors.

Let’s first take a look at best practices for testing apps written in SAPUI5. JavaScript is a dynamic programming language and only some issues can be detected by static code check tools and manual testing. Automated tests that execute the code regularly are beneficial for good quality and development productivity - especially when you're developing in short development cycles.

We expect our prototype to be released and shipped as a product soon, so we need a solid testing strategy. Fortunately the prototype team has already thought ahead and prepared a unit and integration testing infrastructure that is included in the app. This is a really good starting point for further enhancements of the app.

The mock server is also set up and allows us to test the app with local test data instead of a real back-end service. We can use the mock data for writing reliable integration tests that do not depend on another system which might be unavailable when the tests are run.

Before you start implementing your first test, you should think about how to test the different aspects of your application. The image below shows the testing tools along the agile testing pyramid.

Figure 3: Testing pyramid

When we think about application testing, we want to automate as many testing steps as possible. When we immediately write a test for all the features that we implement then we can greatly reduce manual testing efforts that are time consuming and cumbersome. Whenever we change something later, we can simply run the existing tests and see if the functionality is still working as expected.

The two testing tools that are included in SAPUI5 are QUnit for unit testing and OPA5 for integration testing. The foundation for our testing pyramid are the unit tests and they should validate the most important logic of our app. On top, we can write integration tests for more interaction-related functionality like interacting with UI elements of the app.

• Write unit tests in QUnit for more logic-related functionality

• Write integration tests in OPA5 for user interaction

• Separate productive and non-productive code within the app (webapp, test folder)

• Provide a local test page that triggers the app in test mode with mock data (test/mockServer.html)