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.
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:
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.
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.
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.
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.
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.
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.
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:
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:
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:
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
The result of the expression is sent to the “Expression Tester Result Window”, which displays the value as a tree.
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 { instance UnitTestGroup reference { |
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 instance UnitTest TestContentExtraction { instance UnitTest TestNoExecution { instance UnitTestGroup TestGroupExtractions { |
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”.
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.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.