Software QA FYI - SQAFYI

Quality Assurance with JDeveloper 11g and 12c


The tutorial focuses on creating audit rules for the Oracle ADF. That said, this is a JDeveloper feature and in the same way, you can write audit rules for Oracle Service-Oriented Architecture (SOA) Suite or any other JDeveloper project.
Introduction to QA
In a software development process, quality assurance (QA) is usually postponed until the very end, when there is little to no time left. After functional testing, bug fixing and—optimally—performance testing your application, there might be some time left for writing documentation. With that, the project ends.
In our experience, one of the main reasons for this (bad) habit is that QA tools usually are not embedded into the development process and, if they are, they are time consuming and cumbersome, with little perceived benefits to the developer.
Take SonarQube, for example, one of the most powerful QA tools. It typically operates on committed code from the source repository, and might report major issues, forcing the developer to take a second look at the code. This takes place after the code has been committed to the repository and, in most cases, the developer will have moved on to implementing the next functional requirement. And might experience the SonarQube report as a time-consuming nuisance, instead of enjoying the quality of the code going up.
Luckily, JDeveloper offers a solution. JDeveloper continuously checks your code and reports QA issues to you as you are developing. Issues will show as yellow or red indicators in your source code. This auditing framework is very powerful to begin with, and can be extended further with your own company- or project-specific rules.
The JDeveloper Audit Framework
JDeveloper comes with a standard framework to report quality issues and possible solutions to the developer. This is where the “light bulbs” come from that you see in the editor gutter when JDeveloper is trying to tell you something. It is also where the underlined warnings and errors come from inside your code. This works both for Java and XML files, covering nearly all files in a typical JDeveloper project.
You can modify the behavior of this framework in the Audit page of JDeveloper's preferences dialog. This includes a Profiles page where you can configure different audit profiles. You can share them using export and import. You can also select which profile should be used for the continuous auditing while you are coding.
Once you've set up a profile to your liking, you can use the Build menu in JDeveloper to run this profile against a workspace or a specific subset of files within this workspace. JDeveloper gives you a quick report of the violations within these files; you can export this report to XML or HTML to share or use in other tooling.

If the rules provided by JDeveloper or one of its extensions are not of your liking, you can create your own JDeveloper extension and write your own custom audit rules.
Setting up an extension project in JDeveloper is relatively simple. Start by downloading the Extension SDK through JDeveloper to check for updates and then create an Extension Application. In this application, you must focus on three main files during the creation of a custom audit rule. is the resource bundle where all your labels and messages are.
extension.xml is where you declaratively define your audit rules.
Analyzer class(es) are where the actual magic happens.
The resource bundle is a straightforward property file that uses key value pairs to define your resource keys and the assigned value. Refer to these keys in extension.xml so that at run time JDeveloper can look up the value (label) for the assigned key.

The extension.xml is a file where you define a so-called audit-hook, which is a hook in the framework to declaratively define your audit rule and its properties. These are properties such as the ID, the default severity and the category it is in.
You also define one or more triggers and one or more analyzers for this audit hook in extension.xml. The triggers do as the name suggests, and trigger the audit-hook when a certain technology is used in a project. For example, a trigger with technology ADFbc will fire Analyzers for an ADF Business Components project, while a trigger with technology JSF will fire Analyzers for a Java Server Faces project. You can define multiple triggers and analyzers for each audit-hook you are creating.
The analyzer is where the actual checks happen and is programmed in Java. This java class is a subclass of oracle.jdeveloper.audit.analyzer.Analyzer. This Analyzer class provides enter and exit methods on constructs both for Java and XML files.
Analyzer class:
In the Analyzer class, you program your rule logic. The Extension SDK API gives a pretty good idea of what an Analyzer does:
"The Audit framework traverses the constructs of the object models corresponding to the nodes being audited and at each construct invokes the applicable enter and exit methods of each registered analyzer."
The traversal is done depth-first, resulting in the child construct enter method being called after its parents' enter method on the way down ,and the child construct exit method called before its parents' exit method on the way up. The best practice is to collect information in the enter methods, while reporting violations during traversal back up through the exit methods, when all information on children has been collected.
The method signature of the enter and exit methods accept two parameters: the AuditContext (more on this later) and the construct being analyzed. For each construct, the most specifically-typed method that accepts the construct will be called; for example, a method accepting a java.lang.Object will be invoked for each construct while one accepting org.w3c.dom.Attr will be invoked only for xml attributes. For performance reasons, be as specific as possible with your method signature to prevent too many invocations.
The AuditContext (which is an instance of oracle.jdeveloper.audit.analyzer.AuditContext) is used to report violations and/or measurements to the framework. However, AuditContext can also be used in the enter and exit methods to provide information about the current state of the traversal. You can use this to set attributes on the context for later use in child constructs. You can even use the AuditContext to share attributes between different analyzers if you're required to do so.
Creating Custom Fixes
Once you have set up your audit rule and thrown a violation to report to the user what is wrong with the code, you can also program a fix for this rule, as signified by the light bulbs that JDeveloper shows in the editor gutter. Clicking the light bulb will give you one or more solutions to choose from. Once you pick an option, your code is reformatted and rewritten into a suggested solution by the framework. This behavior is what we call a "fix" and, just as for custom rules, you can create your custom fixes to implement this behavior.
In your extension project, you need to edit the extension.xml file to register your transform class in the audit-hook and add a transform binding to your audit rule to register this transform as a fixer for that rule. As with the Analyzer, the transform class is where the actual magic happens to write a fix in java code.
This transform class need to be a subclass of the oracle.jdeveloper.audit.transform.Transform class, and has a single apply method that makes the necessary changes to the source object. For advanced scenarios, the transform can even ask the user for additional input before applying the fix.
Violations Overload
After happily coding all your rules into a great extension project, you start to deliver this useful extension to your coworkers, family and friends, because we all want to benefit from this amazing tool. If so, it won't take long before you will start hearing people complain about all the violations they have and how in some cases this shouldn't be reported because they deliberately chose to program their code this way. There might be times when you want to ignore the reported violation.

Full article...

Other Resource

... to read more articles, visit

Quality Assurance with JDeveloper 11g and 12c