Introduction to the test methodology for PL/SQL libraries

Presentation of the articles series

Discussing about a methodology to test PL/SQL frameworks and libraries seems too long and technical to be done in one article. So I decided to split the article in seven parts (one by category to evaluate) to give you something more digest and let you give your feedback on a limited number of subjects. You will have a weekly “pill to take” and talk about the effects.

We start the series with this article.

Introduction

Testing PL/SQL frameworks and libraries demands a lot of work and a method is necessary to evaluate multiple tools with different features and different approach of the development.

As developers, we all have different sensibilities and each people has to find his own comfortable path to develop. With these tests, I just want to highlight the strengths and weaknesses of the tools to let you choose which one better fits your needs with a maximum of information.

That is why I publish the methodology and ask you to help me to build the most "objective" one.

Information on frameworks and libraries

In this article I define a library as a collection of functions and procedures on a specific topic and a framework like a collection of libraries. And of course, one of the greatest interests of a framework is the compatibility between its libraries.

I will use here the word of library to indicate a library or a framework.

To have an overview of each library, I will provide the following information on each one :

• Type (framework or library)

• Type of release (alpha, beta, production...)

• Version of the release

• Start date of the project

• Date of the last version

• Translations available

• Number of developers

• Web site

when they are known.

General principles of the notation

As it is difficult to compare numerous libraries that does have not the same features and documentation, I will note all the features or documentation present in each one.

The features and documentation will be group in categories.

The note for each feature or documentation will be summed to give a note to their category.

If a feature or documentation only exists in a library, only this one will be noted. Others libraries will have 0 for that feature or documentation.

It means that the notes of the categories are not limited, it is an open notation.

Moreover some extra points can be given in some conditions (if no DBA action required for example).

Anyway, a notation reference is detailed before the each evaluation of a category.

The main categories to evaluate

I have identified seven categories than should be evaluated :

1. Install/uninstall and upgrade

2. Ownership and support

3. Development features

4. Documentation

5. Interoperability

6. Code quality & architecture

7. Performances

Install/Uninstall and upgrade

Notation

Prerequisites :

• 0 point if several prerequisites

• 1 point if one prerequisite

• 2 points if no prerequisite

Scripts :

• 0 if it does not work (>15 min to use it) or it is not present or if the results are not reproducible

• 1 point for >10 min to use it

• 2 points for >5 min and <10>

• 3 points for <5>

Bonus :

• 1 more point if no DBA action is required.

• 1 more point if the number of objects created by library is less or equal to 10

Features to evaluate

• Installation or upgrade :

• Install script : from scratch

• Upgrade script : from a previous version of the library

• Example : a script or package is given as example to verify immediately that the library works correctly.

• Prerequisites : dedicated schema, administrator rights, others.

• Number of objects installed : Packages, tables, views, sequence...

• Uninstall :

  • Uninstall script : from the last version of the library

  • Cleaning of the installed objects.

This is the end of the first article of our serial. I am waiting for your feedback, ideas and contributions. It is up to you now !

And see you next week for the second article...