31. 03. 2020 Michele Santuari NetEye

How Do We Test NetEye?

Since my latest blog post on the new Front End automated tests, we have improved our Continuous Integration process. In this blog post, I describe, from the developer’s perspective, a couple of important enhancements and what we would like to achieve in the upcoming months.

The introduction of pull requests has been the first change: they’re a fast way to compare a set of changes introduced by a bugfix or a new feature. Even though we’re used to doing code reviews, the pull request simplifies the comparison and allows adding comments directly to the code.

some icons have been changed: compare old (left) vs new (right) versions

In addition, we’ve implemented a mechanism to validate the changes automatically as soon as the pull request is created. If all the tests are executed without errors and the code is aligned with the latest version, the Continuous Integration system automatically approves the pull request. As soon as it’s approved, a developer can start the review process. In this way, we have managed to reduce the time spent reviewing changes that might break the tests later on in the process.

The user SI Development approved the pull request: all tests are passing and the branch is aligned with the latest version

Since NetEye 4.0, we have monitored the R&D infrastructure with a productive NetEye installation (called R&D NetEye) which has been kept up-to-date with the latest beta features (i.e., not-yet-released features and bugfixes).

Recently we decided to collect, through our R&D NetEye instance, some more advanced metrics from the Continuous Integration system. The goal is to determine those tests which require more attention and to gain better control over a set of APIs calls that are used to retrieve information needed in the building process. Thanks to the following dashboard, we’ve been able to fix a couple of scripts that were executing far more API calls than expected, thus causing unexpected issues.

The top part of the Figure shows the failed tests: in this case, we had a problem with a library.
The bottom part displays how the number of API calls drop as soon as we fixed the script.

To conclude, I think that the Continuous Integration process is really important for the R&D team to guarantee the correct integration of all the components, and to deliver a better customer experience.

For these reasons, the R&D Continuous Integration system must be continuously improved. In the next months we will focus on speeding up the building and testing time (e.g., our current worst-case scenario is the automated building and testing of NetEye with all components, which currently takes about 40 minutes) by:

  • Improving our initial test setup library to create a common environment for all our components in order to drastically reduce the setup time of all the tests
  • Changing the approach of our testing pipeline to parallelize tests (e.g., one instance executes the Front End test and another the integration)
Michele Santuari

Michele Santuari

Software Architect at Wuerth Phoenix
Hi, my name is Michele Santuari and I am a Telecommunication engineer felt in love with OpenFlow, the first attempt of centralized network management, provisioning, and monitoring. I embraced the Software Defined Networking approach to discover a passion for programming languages. Now, I am into Agile methodologies and crazy development process management.

Author

Michele Santuari

Hi, my name is Michele Santuari and I am a Telecommunication engineer felt in love with OpenFlow, the first attempt of centralized network management, provisioning, and monitoring. I embraced the Software Defined Networking approach to discover a passion for programming languages. Now, I am into Agile methodologies and crazy development process management.

Leave a Reply

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

Archive