Everything is moving to the cloud

It seems like everything is moving to the cloud and a web browser is used to access the data. Code coverage is joining that movement. You will see how the transition started in IDz 14.1.5 and is being extended with the introduction of Code Coverage as a Service (CCaaS). 

Don’t worry… This doesn’t mean that we are moving away from IDz, rather, we will continue to enhance and extend IDz’s experience. In fact by implementing CCaaS we will be able to support a more flexible method of collecting and interacting with code coverage data.


In IDz 14.2 we include the initial version of CCaaS disabled. We felt it important to include the function so that we can get early feedback. Later in this article I’ll describe the simple steps required to enable CCaaS so that you can try it. If you enable CCaaS, you can continue to use IDz and code coverage as normal. CCaaS will run in the background and you can do your normal work without being impacted.

The movement began in IDz 14.1.5

1) The web view replaced the Eclipse view to display code coverage results

No doubt you noticed the new results view. (The new Code Coverage web reports in IDz 14.1.5)

There were several reasons for this change related to our discussion of CCaaS:

  1. Code coverage data can now be displayed both inside and outside an Eclipse based application (IDz) in a consistent way.
    • You can try this for yourself by following these steps:
      1. Open some code coverage results.
      2. RMB (Right Mouse Button) anywhere in the results and select “Properties”.
      3. Copy and paste the URL into a web browser.
        NOTE: by design this will only work on the same machine. The URL can not be used to access your data from another machine.
  2. The data can be displayed with just a web browser. Nothing needs to be installed on the client. This will allow code coverage results to be displayed in many more situations where only a browser is available. For example looking at results generated during a build. IDz will access code coverage data stored in CCaaS and will have a more interactive experience.
  3. Data doesn’t have to reside on the client to be displayed. This is key. Until now it was a requirement that a copy of the data be local to the client. Even remote directories required a local copy. The web view allows remote access to the data.

2) All code coverage data is now accessed through the CCAPI

This change is not as obvious because it is an internal change, but is equally important. All code coverage data is now accessed through the CCAPI (ccapi.jar). CCAPI can import and export code coverage data in various formats and allows for components to interact with code coverage data using a consistent interface. Several of the older Eclipse views accessed the raw data formats and this limited their use. By using a consistent interface, all views and components that need to access code coverage data can do so without needing to know the various raw formats. It also supports an exporter framework that can produce SonarQube® and PDF formats.

Documentation for the CCAPI can be found at this link https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_14.1.0/com.ibm.codecoverage.javadoc.doc/index.html

The link contains the option to see the version of the CCAPI found in the version of IDz. The latest version of IDz 14.2 contains the v10.0.0 version of the CCAPI.

Another blog will outline how to get access to the ccapi.jar to interact with code coverage data through a program interface.

Introducing CCaaS in IDz 14.2

Why CCaaS?

Before discussing what it does, it would be good to discuss why CCaaS is required.

Code Coverage as a Service gives us:

  1. Central collector of coverage results.
    Becomes a single point that can collect code coverage results from the various components that generate it.
  2. Central provider of code coverage result data.
    Create a single point that can serve up code coverage results without the need to read raw data files.
  3. Provide a RESTful API for code coverage collection and result retrieval.
    Using a URL, code coverage data can be uploaded to CCaaS and can then be queried for coverage statistics. More on that later.
    I encourage you to search for “RESTful” to see why this is an important style of API.
  4. Provide a simple single solution for working with code coverage data.
    Our goal is to make code coverage collection as simple as possible without a complicated install and CCaaS is an important part of that solution.
    e.g. We are investigating the use of a single docker image that would include the functionality of the “Headless Code Coverage” collector and CCaaS that can collect and serve up code coverage data.
  5. Ability to run in many different platforms and environments.
    Only requirement is a web server, Java JRE and access to local storage to save code coverage results.

What is CCaaS?

CCaaS is a service that runs in any web server. In this initial release it uses the Jetty server built into the Eclipse that IDz is based on. This is the same Jetty server used to display help in the product. When it has been enabled it is only available as long as IDz is running. When IDz is exited the Jetty server and CCaaS is stopped.

When CCaaS is started, it can be accessed using a web browser. For example, if CCaaS is started on port 8010 the URL to check that CCaaS is up and running is:

http://localhost:8010/ccaas/ping

If CCaaS is started and working correctly you should see the following response:

The format of the response is JSON. Another term to search! It is a common response format for a RESTful API. In the above example several fields are returned.

  • messages : a welcome message is returned
  • version : the current version of the CCaaS (please note that this is work in progress and therefore the version number reflects that)
  • storageFolder : the directory used to store code coverage results

The next useful request gets us the documentation for the RESTful services that CCaaS provides.

This one is simple… just the base URL

http://localhost:8010/

You will see the following response:

This documents how you can interact with CCaaS running inside IDz. In the future this API will be expanded as new features are added and there is a very good chance that this API will change.

Even though it might change, feel free to take a look at the various calls that are supported and even try them. The documentation includes examples.

Enable and interact with CCaaS

Steps to enable CCaaS:

  1. Find the directory where IDz is installed. You should see an executable called “eclipsec.exe” on windows.
    NOTE: this example uses Windows but it also applies to other platforms that the IDz client supports.
  2. Start a power shell or command window in the above directory.
     
  3. Enter the following to activate CCaaS, choose a port that is not being used. Port 8010 was used for this example.
    “eclipsec.exe” is used because it keeps the command window open so we can see any messages that may be displayed.
    .\eclipsec.exe -vmargs “-Dccaas.port=8010”
    Note: CCaaS will stop running when IDz is exited.
  4. After IDz starts and CCaaS is running, the “Code Coverage Results” view will display a new entry. This is IDz interacting with CCaaS using the RESTful API to retrieve results stored in CCaaS.

The next step is to import a result into CCaaS.

In a future release results will automatically be pushed to CCaaS but for now they need to be imported.

  1. RMB on the “CCaaS Workspace Results” and select to import a result.
  2. Choose a result to import. In this version the only type of result that can be imported is a .cczip format. This may require exporting an existing result to the local file system before trying the import.
  3. After import it should look like this:
  4. Interact with this result in the same way as a locally stored result. Open the result to display the content.
    This might look exactly the same as if the result was opened as a local result. BUT there is a key difference. The interaction with the result is completely through the RESTful API. That means that the result could have been remote to the IDz client. If CCaaS had been running in a remote web server the interaction with the result would be the same as if it was local!

Work with results stored in CCaaS

  1. For the next step import another result. It should look something like this with similar files but different coverage results:
  2. Now open the following URL in a web browser (replace the port # if different):
    http://localhost:8010/ccaas/webapp/#/ccResultView
  3. This should display a web version of IDz’s “Code Coverage Results” view:
  4. Same results but accessible from a web page.
  5. Click on the results and they will open in a web page exactly the same as in IDz.
  6. Select 2 results and choose compare. The options that are based on what is selected.

  7. If you click on a file the contents of the source or listing are opened in a web page and annotated with code coverage indicators.
    H – Hit and X for eXecutable but not hit.

    Displaying source or listing content in IDz is much better because it supports language tokenizers that add colour to the source. The above example shows how we might display coverage information without needing a rich client like IDz.

Summary

We are moving code coverage to the cloud by implementing Code Coverage as a Service.

It will:

  • Provide a centralized collection point for all code coverage data.
  • Provide a centralized point for working with and displaying code coverage data.
  • Support rich client and web based interaction with code coverage data.
  • Support RESTful APIs to access the data.

Eventually CCaaS that ships in IDz will be enabled and used by default.

Please take some time to try it out and give us your feedback that will help us enhance this feature in the future.

Join The Discussion

Your email address will not be published. Required fields are marked *