End-To-End setup of local development environment with UI5 Tooling – Part 6 Code Coverage

Hello again.

I’ve decided to add one more blog to this series

• End-To-End setup of local development environment with UI5 Tooling
• End-To-End setup of local development environment with UI5 Tooling – Part 2
• End-To-End setup of local development environment with UI5 Tooling – Part 3 VS Code
• End-To-End setup of local development environment with UI5 Tooling – Part 4 Component reuse

• End-To-End setup of local development environment with UI5 Tooling – Part 5 Deployment

This time we will cover code coverage. I’ve experimented with this in the past, but really never found an easy way to cover it. Yes we could use OPA5 and QUNIT. But frankly I find them too time consuming to write compared to the value. At my current client site we are using Selenium to do integration testing, which covers a lot of what we would cover in OPA5 testing. And could we even use this while we are doing manual testing?

Now I always thought it would be cool if we could get our Selenium tests to submit statistics of how much of our code has been covered.

So let’s start with what is Code Coverage actually?

Well looking at Wikipedia, they have this definition:

In computer science, test coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. A program with high test coverage, measured as a percentage, has had more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low test coverage.^[1][2] Many different metrics can be used to calculate test coverage; some of the most basic are the percentage of program subroutines and the percentage of program statements called during execution of the test suite.

Now when we have code coverage statistics are gathered for our application on different parameters

Basic coverage criteria

There are a number of coverage criteria, the main ones being:^[5]

• Function coverage – Has each function (or subroutine) in the program been called?
• Statement coverage – Has each statement in the program been executed?
• Edge coverage – has every edge in the Control flow graph been executed?
• Branch coverage – Has each branch (also called DD-path) of each control structure (such as in if and case statements) been executed? For example, given an if statement, have both the true and false branches been executed? Notice that this one is a subset of Edge coverage.
• Condition coverage (or predicate coverage) – Has each Boolean sub-expression evaluated both to true and false?

Now there is a very cool tool for Javascript for this called Istanbul which does exactly what we want. But how to implement this into our development.

Well I got busy and created a NPM package that does exactly that.

So let’s give it a whirl!

First we need to install it into our project

npm install ui5-middleware-proxy-basicauth --save-dev

Similar to last time, we add it to our package.

"devDependencies": {
    "ui5-middleware-code-coverage": "*"
},
"ui5": {
  "dependencies": [
    "ui5-middleware-code-coverage"
  ]
}

Now we add it to the yaml file

server:
  customMiddleware:
  - name: ui5-middleware-code-coverage
    afterMiddleware: compression
    mountPath: /
    configuration:
      path: "webapp"
      enabled: "false"

The path is which folder you want to instrument. And the enabled is a switch you can use to easily turn the code coverage on or off. This is handy as the instrumented code can be hard to debug.

That’s it. Let’s see it in action! Run the command:

npm run-script start

In your terminal you should see something similar to this:

So code coverage is now running on port 3000.

When you inspect the http://localhost:3000/coverage url. Nothing is there!

Well duh! we haven’t added anything yet.

So run your application and open the web debugger.

If you write the following in the console

window.__coverage__

You should see something similar to below

Now let’s just submit this to the code coverage

The following code will do that

$.ajax({
  type: "POST",
  url: 'http://localhost:3000/coverage/client',
  data: JSON.stringify(window.__coverage__),
  headers: {
    'Accept': 'application/json',
    'Content-Type': 'application/json'
}
});

It’s also possible to use Python for your selenium scripts to do this. Check out this blog on how to do that.

Now if we check our coverage again, we can now see our code coverage. Neat right!

And you can drill into the files and see exactly what code was hit.

You can resubmit the coverage as many times as you want to the collector by using the ajax script provided above.

Also once done you can run

http://localhost:3000/coverage/download

To download the coverage report in a ZIP file.

Well that’s all guys.

Please let me know of any issues by raising issues on the github page or in the comments below.

Also if you feel I’ve missed something in this blog series, I’d be keen to hear about it.