Projects:Role Inheritance/QA

Introduction

The Role Inheritance project has been developed using the Test Driven Development approach. Following this development process, a set of tests were created at the beginning of the project.

At the beginning, these tests finished with error because the implementation did not exist. This way, as the required functionalities were added, the result of the tests turned into success.

Also, several tests were added before implementing the most part of new features that where included during the project.

Functional

• Several functional tests cases have been executed manually to create different (horizontal and vertical) hierarchies based on inheritance, like the ones described here.

• Automatic Tests: the result of the test development done during the project is a test suite that covers all the basic scenarios available when working with Role Inheritance. The code of this test suite can be found here.

• A set of tests with descriptions about some of the basic functionalities were prepared for TestLink, they can be seen in the following sheet.

• Along this project, several code review iterations have been done in order to improve the quality of the code. In the following sheet can be seen the details of each review.

Performance

The performance tips of this project has been analyzed following the performance decision flowchart.

Regarding concurrency it is not expected a high quantity of requests making use of the Role Inheritance processes at the same time. This is because this functionality is intended to be executed on an initial stage: during the General Setup in order to ease the roles setup process.

There is one element which needs to be concurrently efficient: the RoleInheritanceWarningFICExtension class is used to show a warning message to the user under some circumstances, before creating or editing a record. As a FICExtension, it is executed after every request done to the FIC, so its execution must be as fast as possible.

To achieve that, this class uses a cache to keep in memory the information used to determine if the message must be shown. This way, unnecessary calculations are avoided. The implementation of this cache mechanism resulted on saving an average of a 99% of the time spent for this process, when the information is already present in cache.

To measure the scalability of the processes, it has been done tests with volumes of data higher than the expected on a standard environment. In those tests different hierarchies and volumes of data have been used as described in this sheet. Basically, three different types of measurements have been tested:

• Propagation time of a change through a hierarchy when creating, editing or removing a permission of a template role. This is the most common use case in Role Inheritance and therefore it is important to have a good performance here.
• Cost of adding an inheritance with a high set of permissions on top of a hierarchy. This is the most expensive scenario possible in terms of time cost, but is not the most usual. We needed to measure how expensive can it be.
• Time of process recalculation.

The java processes involved in this project make intensive use of DAL as the behavior of the inheritance creation and access propagation is controlled by Event Handlers. It has not been detected any memory leak on the execution of the handlers during the tests.

When reading large volumes of objects from the database it is important to use specific querying/scrolling techniques to prevent out-of-memory exceptions, like using ScrollableResults instead of DAL lists. But, in the Role Inheritance management processes is not expected to handle large volumes of objects (role permissions), so for the moment, the implementation is making use of lists.

One of the multiple refactors developed inside the project was done with the objective of converting one the central classes, RoleInheritanceManager, into an ApplicationScoped class. No negative performance impact was detected after this refactor.

Regarding javascript, this project just makes use of it in a small part of the manual process called Recalculate Permissions. In particular, the process is used to:

• Show a confirmation pop-up to the user before launching the process.
• Display the results in the User Interface.

So, this new javascript code does not have performance implications.