2022 June Release

Testing and DebuggingPermanent link for this heading

This chapter covers testing and debugging of Fabasoft app.ducx projects, and introduces you to the Fabasoft software products that support you in the testing and debugging phase of the software development life cycle.

Fabasoft app.ducx includes built-in tracing capabilities for diagnosing problems, and lets you use the debugging facilities of your development environment to debug your source code in a convenient and efficient manner.

The Fabasoft app.ducx unit test allows you to automate the testing process when doing unit testing to ensure that your code still works correctly as you change it.

The integration of Fabasoft app.test allows you to automate the testing process when doing user interface testing to ensure that your code changes applies to the user interface correctly as you change it.

Fabasoft app.telemetry provides a highly advanced measuring and profiling software which allows you to record the activities of your software application on each component of the Fabasoft reference architecture.

Tracing in Fabasoft app.ducx ProjectsPermanent link for this heading

The built-in tracing functionality of Fabasoft app.ducx produces extensive traces of your use case implementations

It is enabled in the project preferences dialog box of Eclipse.

There are some different sources of trace information:

  • errors that occur during runtime
  • %%TRACE, %%FAIL and %%ASSERT directives are evaluated for your software component
  • the invocation of each use case of your app.ducx project produces extensive trace output

The trace output contains detailed information about all use cases invoked by your use case implementations, along with the parameter values passed to and returned by the invoked use cases to allow you to get a complete picture of the call stack.

Display Trace Messages in EclipsePermanent link for this heading

Fabasoft app.ducx extends the Console View to display trace messages from the default web service.

In the Eclipse preferences the trace output level can be customized. The client timeout defines the timespan the client waits until it sends the next request to the server. The server timeout defines the timespan the server waits maximally until the response is sent. Lower values increase the network traffic.

The trace console is restricted to a fixed amount of characters. Older lines are removed automatically in the background.

To get all trace lines, saving the trace messages is recommended. The output folder, the maximum size of each output file and the number of files can be specified. When an output file has reached the maximum size a new one is created, when the number of files is reached the oldest one is deleted. The newest file is always trace0.log. A blank Number of Files field means infinite number of files.

Tracer messages can be filtered by Java Regular Expressions. You can define a set of regular expressions and whether the trace messages matching the expressions should be included or excluded. When no filter restriction is enabled, every message is included and nothing is excluded. The specified restrictions can be enabled or disabled.

Tracer ViewPermanent link for this heading

A different view to the trace is provided by the “Tracer View”. The trace flags in “Preferences” are also used for this view.

This view contains buttons to start and stop the tracer. If not running while executing an expression it is automatically started and after completion of the expression stopped.

The “Tracer View” maintains tree nodes for every executing thread.

CoveragePermanent link for this heading

Code coverage is a measure known from software testing. It describes the degree to which source code of a component has been tested, e.g. by executing a unit tests or app.test tests.

When compiling a Fabasoft app.ducx project, any relevant line is recorded and the resulting metadata will be a part of your component. Coverage can be measured, when tests are executing within a coverage session.

A coverage session can be started interactively or using ant tasks or with an expression by calling the action FSCAPPDUCX@1.1001:StartCoverage. Currently pure line coverage is used.

A coverage session will live until it is explicitly stopped interactively, by the ant task or by calling FSCAPPDUCX@1.1001:StopCoverage. Sessions not stopped at service shutdown will be persisted and restarted at service startup. Coverage data files are provided for every software component.

The ratio between all touched lines and executed lines is your coverage.

Expression Coverage

Any Fabasoft app.ducx expression contained in a Fabasoft app.ducx project is instrumented by recording all executable lines. When executing within a coverage session, all executed Fabasoft app.ducx expression lines are touched.

Model Coverage

Currently object class properties are instrumented. Model Coverage is based on accessing object properties. Every time a property of an object class is accessed, the corresponding source code line is touched.

Debugging Fabasoft app.ducx ProjectsPermanent link for this heading

Fabasoft app.ducx allows you to debug use case implementations from within your development environment.

You have to create a new debug configuration before you can debug an Fabasoft app.ducx project in Eclipse. To do so, click “Debug Configurations“ on the “Run” menu.

In the dialog box, select “Fabasoft app.ducx” click the “New launch configuration” symbol and enter a Name for the new launch configuration and select the Project by clicking “Choose“. To specify how the Fabasoft app.ducx project should be debugged, click the “Debug” tab. Following options are available:

  • Attach
    If this check box is selected, the Fabasoft app.ducx project is not uploaded before the debugging session starts.
  • Suspend
    • On error
      If this check box is selected, the execution stops on errors.
    • On warning
      If this check box is selected, the execution stops on warnings.
    • On commit
      If this check box is selected, the execution stops on commits of transactions.
    • On abort
      If this check box is selected, the execution stops on aborts of transactions.
    • On query
      If this check box is selected, the execution stops when a search query is executed.
    • Block until command
      If this check box is selected, the execution stops on break points.
  • Transport
    • Include result nodes
      If this check box is selected, the debug output is rich in detail. Keep in mind that the data to be transferred may be extensive.

Click “Apply” to save your settings, and “Debug” to debug the Fabasoft app.ducx project.

Breakpoints

Breakpoints can be set in every app.ducx Expression block with one of the following methods:

  • Insert the %%DEBUGGER; directive in the Fabasoft app.ducx Expression.
  • Double-click on the left margin of the source code editor.
  • Select the desired line and use the shortcut Ctrl + Shift + B.
  • Open the “Run” menu and click “Toggle Breakpoint”.

Note: Microsoft Windows: To extend the time a thread is kept in the application pool when waiting on a break point, set the (Default) value to 2147483647 of following registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Fabasoft\FscWeb\Modules\FSC\FSCVEXT_MAXREQUESTMSECS]
In normal circumstances this should not be necessary.

Debug Perspective

The debug information is displayed in the debug perspective. To switch to the debug perspective, open the “Window” menu, point to “Open Perspective” and click “Other”. Select “Debug” and click “OK”. The Debug perspective provides you debugging information like the call stack, values of variables and so on.

Following common debug commands are available:

  • “Resume”
    Resumes the execution until the next thread suspending event like a break point is reached.
  • “Terminate”
    Terminates the debugging session and the suspended threads resume.
  • “Step Into”
    The currently selected line is executed and the thread suspends on the next executable line of the called method, if the method is also implemented as Fabasoft app.ducx Expression within the same Fabasoft app.ducx project. Otherwise “Step Over” is carried out.
  • “Step Over”
    The currently selected line is executed and the thread suspends on the next executable line of the Fabasoft app.ducx Expression.
  • “Step Return”
    The currently selected line is executed and the thread suspends on the next executable line of the calling Fabasoft app.ducx Expression.

Expression TesterPermanent link for this heading

The Expression Tester works on all files in the project, either for the whole expression in expression files with the extension ducx-xp or inside of any expression element.

To use short references, imports can be used, just like in all other domain specific files.

The expression can be fired against the current web service by selecting “Run as... Expression” from the context menu. The shortcut for this is Alt - X.

As long as the expression is running, the “Expression Tracer View” is activated and displays the trace lines.

This view

  • separates the output from different threads,
  • shows a call stack,
  • can be filtered.

The result of the expression is sent to the “Expression Tester Result Window”, which displays the value as a tree.

Testing Use Cases With Unit TestsPermanent link for this heading

Fabasoft app.ducx unit tests allow automating the testing process to ensure correct working code throughout the whole development cycle. One even could adopt test driven development by implementing a unit test for the required functionality first.

Syntax

instance UnitTest reference {
  test = expression {...}
  testdata<tdid,tdcontent> = {...}
}

instance UnitTestGroup reference {
  tests = {...}
}


Unit tests are instances of the object class FSCDUCXUNIT@1.1001:UnitTest and identified by references. Each unit test consists of one test expression, which is stored in the property test.

Note: In unit tests the private flag of component objects is ignored.

The aggregate testdata consists of the string property tdid and the content property tdcontent.

A unit test group is an instance of the object class FSCDUCXUNIT@1.1001:UnitTestGroup and identified by a reference. A unit test group holds in the property tests a list of unit tests. All unit tests listed in the property tests are executed in the specified order, skipping tests with the property inactive set to true.

Example

objmodel APPDUCXSAMPLE@200.200
{
  import COOSYSTEM@1.1;
  import FSCDUCXUNIT@1.1001;

  instance UnitTest TestContentExtraction {
    test = expression {
      content zipfile = #TestContentExtraction.testdata[tdid == "zip”].tdcontent
      ...
    }
    testdata<tdid,tdcontent> = {
      { "zip", file("resources/data.zip") }
      ...
    }
  }

  instance UnitTest TestNoExecution {
    inactive = true;
    test = expression {
      ...
    }
  }

  instance UnitTestGroup TestGroupExtractions {
    tests = {
      TestContentExtraction,
      TestNoExecution
    }
  }
}


In a domain, unit tests can be started manually. To do so, click “Run Test“ on the context menu of the unit test or Run Tests on the context menu of the unit test group object.

Unit tests can be integrated into an automated build and test environment using Fabasoft app.ducx Ant tasks. Information about Ant tasks can be found in chapter “Fabasoft app.ducx Ant Tasks”.

Testing Use Cases With Fabasoft app.testPermanent link for this heading

Fabasoft app.test allows testing implemented use cases in a convenient way. Recording and playing of interactions happens within a context-sensitive user interface. This means that rather than simply recording mouse moves, clicks and keyboard strokes, objects in the user interface are called instead.

For further information on Fabasoft app.test and to learn how to define app.test use cases, please refer to the white paper “Fabasoft app.test”.

Fabasoft app.telemetryPermanent link for this heading

Fabasoft app.telemetry is a revolutionary measuring and profiling software. This tool allows you to record the activities of any software application at runtime spanning all layers of the reference architecture.

Using the collected data, you can easily analyze the processing steps of requests.

For the collection of data as requests are processed, so-called measuring points have been added to all services and the kernel. These measuring points remain deactivated as long as the recording of request data is not initiated using the Fabasoft app.telemetry Control Center Management Interface.

The seamless integration of Fabasoft app.test allows for a detailed analysis of app.test use cases and use case sequences using the Fabasoft app.telemetry Analyzer tool.

Fabasoft app.telemetry is an essential tool for every software component developer as it allows you to evaluate the effects of hardware, software and configuration changes.

The Fabasoft app.telemetry Analyzer combines the data of different services to give you an overview of the performance impact of processed requests. You can then drill down throughout all levels of processing. This way, you can track performance issues down to the use case level so you can optimize use case implementations. Moreover, the Fabasoft app.telemetry Analyzer allows you to drill down even further so you can even see the SQL statements issued on the database server.