Show TOC Start of Content Area

Function documentation Testing Java Applications with JLin  Locate the document in its SAP Library structure

Use

To meet the high demands placed on quality assurance for Java-based application projects, the JLin test tool is provided as an integral part of the SAP NetWeaver Developer Studio.

JLin enables you to investigate the properties of Java source files and check the syntax of their semantics. Checks for metrics, conventions, incompatibilities, authorizations, and language restrictions, for example, are delivered as standard. You can also create and perform your own checks by specifying check parameters. Thus a check run can include several single checks, which can be performed on one or more Java source code files.

After the check run has been completed, the system displays a list containing the test results as information, warnings, or errors, along with location of the problem in the source code. Thus JLin is a suitable development tool that you can call either in a Java program or as a plug-in.

JLin

You use JLin to perform predefined static tests on Java sources. The tests are delivered as part of the SAP NetWeaver Developer Studio. Uses include:

·        Identifying error sources

·        Enforcing code conventions

·        Evaluating metrics and statistics

·        Enforcing architectural patterns

·        Monitoring

Features

To configure your tests, in the menu bar choose Windows Preferences Java JLin. All JLin tests along with their parameters are grouped in sets called JLin variants. You can create, edit and remove JLin variants.

Variants

Variants are XML files that include groups of active tests. All the predefined tests are included in the DEFAULT variant. You can perform the following tasks:

·        You can create your own editable variants by copying the DEFAULT variant.

Select the DEFAULT variant in the Variants list and choose Copy… Enter a name for this variant. Choose OK.

Note

The name of the variant must not be an empty string and can contain letters and numbers only.

      You can export variants as XML files. This is useful where a team has a standard variant that everyone in the team should use.

Select a variant in the Variants list and choose Export… Enter a name of the file and select a directory where you want to save it. Choose Save.

      You can import a variant. There is automatic validation of the XML – invalid files will not be imported. If a variant includes tests that do not exist in the importing Developer Studio, the variant can still be imported (you will get a warning) but the missing tests will be ignored.

Choose Import… Browse to the XML file you want to import and enter a name of the variant. Choose OK.

Predefined Variants

If predefined variants are maintained in a central location, you can update selected local variants. Choose Update Predefined… followed by Check for Updates.

You can then select the variants that you want to install or update.

Test Results

For most tests, the results of a JLin test run are displayed in the standard Problems view. You can also select to export the results to a file, which you can later import and display again in the Problems view.

Suppressing Messages

Developers can suppress JLin messages for their own code by inserting pseudo-comments in their code – refer to the individual test descriptions for the relevant pseudo-comments (for example, the Catch Block Test uses the pseudo-comment //$JL-EXC$). By selecting Display suppressed messages only, only these JLin messages will be visible in the Problems view.

Code Classification

Rather than writing pseudo-comments all over your code, you can define rules that suppress tests for certain files. In the context menu of your project, choose Properties. In the screen that appears, choose JLin. Choose New… to create a rule in the Code Classification section.

When you create a rule, you can select the tests to be suppressed from the list.

Priority

JLin messages have a priority level from 1 down to 3. If you select Priority threshold and enter a value for it, only messages of that priority or higher will be visible in the Problems view.

Test Descriptions

Each test has documentation that you can display. Proceed as follows:

...

       1.      In the menu bar, choose Window Preferences.

       2.      Expand the Java node from the list and choose JLin.

       3.      Choose a variant from the Variants list, for example DEFAULT.

       4.      Choose Edit…

       5.      Expand one of the nodes in the list and choose a test.

       6.      In the context menu of the test, choose Display description.

       7.      Choose OK to close the description.

JLinEE

JLinEE tests are part of the DEFAULT variant. By default, these tests are not selected. Although you can select and execute the tests in the normal way, we recommend using project validation to run JLinEE tests. If you choose to use project validation, all the relevant JLinEE tests are executed (selection or deselection is not relevant) each time the project is built.

Tests check the consistency of the XML descriptors in the Java EE projects against the specifications (as far as is possible statically). Before any other tests are run, the schema validation is run. If this test fails for a descriptor, none of the other tests are run on the descriptor.

More information: Executing JLinEE Tests

Procedure

...

       1.      Configure the JLin tests you want to execute.

More information: Creating and Editing Variants

       2.      Test your sources using JLin.

More information: Executing JLin Tests

       3.      Analyze the results from the JLin tests.

More information: Displaying JLin Results

End of Content Area