In this step, we will take a look at the prototype that is handed over to us and define the test strategy for our app. The prototype already contains the infrastructure for unit and integration testing and a minimum set of tests and features.
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:
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:
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.
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.
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.
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.
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 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
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.
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.
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.
If you start developing an app from scratch, you should always consider testing from the very beginning of the software life cycle. Nobody wants to write tests for undocumented code and make assumptions about the logic. It will pay off many times to think about code checks, unit and integration testing and a solid testing strategy from the very start.
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.
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.
In this tutorial we will focus on writing clean unit and integration tests for apps. They build the foundation and are crucial for good application quality. We will also outline how to write testable code. Not all implementation patterns can be tested easily. But when writing the test code together with the implementation code as in this tutorial it is a natural result.
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)