How we reached 0 technical debt in our Eclipse project

In this talk we would like to tell our story in testing our Eclipse project, EMF Parsley, and how we used code quality tools like Sonarqube to reach 0 technical debt.

EMF Parsley is an Eclipse project that provides a framework for quickly developing user interfaces based on EMF models. The framework allows for customization via dependency injection. It also provides an Xtext based DSL to quickly and cleanly configure and customize the UI components.

Due to the nature of the project we have several kinds of tests for the different components of the frameworks. When we started working on EMF Parsley, most of our tests were functional tests, based on SWTBot. We had to test the default behavior of our UI components but also the behavior in the presence of possible customizations. While this approach allowed us to test most of the parts of the framework, it was not optimal, especially for the execution time of functional tests and for the programming effort to specify different customization scenarios.

Nowadays, only a small part of our tests are functional tests: the biggest part is based on plain JUnit. Even if we write tests for UI components, we can test their behavior without a running Eclipse workbench, and most of the time we do not even need a Display. We use also mocking frameworks to make our tests cleaner and to be able to test even corner case situations. This way, it is much easier for us to test our components, and it is much faster to run such tests.

This allowed us to reach a good percentage of code coverage. We analyze our project with Sonarqube and we tried to follow Sonarqube issue reports to make our code clean as much as possible. Nowadays, we reached 0 technical debt.

In this talk we will describe our testing techniques and how we reached 0 technical debt.

Schedule info
Session Time Slot(s): 
Wednesday, October 26, 2016 - 17:45 to 18:20
Alexandra Schladebeck (BREDEX GmbH)'s picture


Thanks for the entry. It sounds interesting, and we have a question about your definition of technical debt. We're a bit worried that technical debt means different things to different people - can you elaborate on what you mean in this context?



Public comment
Lorenzo Bettini (Dipartimento di Statistica, Informatica, Applicazioni, University Firenze)'s picture

Dear Alex

We thought that technical debt would be intended in the standard way, at least as we find in these definitions, , . At least, in our meaning, we refer to zero technical debt as reported by SonarQube, implying good code quality, that is, high test code coverage, no code duplication, no cyclic dependencies in code, no issues as reported by SonarQube’s code metrics analysis. Please also refer to our project SonarQube dashboard,

In particular, this talk will concentrate on testing techniques.

Do you think we should change the abstract somehow?

Public comment
Alexandra Schladebeck (BREDEX GmbH)'s picture

Hello Lorenzo

Thanks for answering so quickly. Your comments are clear enough to help us further I think, so you do not need to change anything in the abstract.

Best regards,


Public comment

Our Sponsors

For information about becoming a sponsor, please visit the EclipseCon Europe 2016 sponsor prospectus page.

Elite Dual ECE/OSGi CE



Project Quality Day

IoT Theme Day


EclipseCon Support Other Events

Our Other Events

Eclipse events are hosted all over the world!

  • EclipseCon Europe 2018