ONLINE HELP
 WINDEVWEBDEV AND WINDEV MOBILE

Help / WINDEV concepts / Part 4 - Advanced concepts
  • Overview
  • Testing and debugging a WINDEV project (development computer)
  • Overview
  • Testing and debugging the current project
  • Testing and debugging the executable on the development computer
  • Debugging an executable already run on the development computer
  • Testing and debugging a WINDEV project on the user computer
  • Testing a window
  • Testing a window from the editor
  • Stopping the window test
  • Tracing a project
  • Debugging principles
  • Debugger overview
  • Debugger features
  • Debugging without debugger
  • Performance test
  • Overview
  • Starting the performance profiler
  • Reading the performance profiler results
  • Choosing a process to optimize
  • Regression tests
  • Overview
  • Automated tests
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaReports and QueriesUser code (UMC)
WEBDEV
WindowsLinuxPHPWEBDEV - Browser code
WINDEV Mobile
AndroidAndroid Widget iPhone/iPadIOS WidgetApple WatchMac CatalystUniversal Windows 10 App
Others
Stored procedures
16. Application test in practice
Previous pageTable of contentsNext page
Overview
WINDEV includes multiple methods to test applications:
  • test of the entire project,
  • test of a single window,
  • test of a single query (see the online help for more details),
  • test of a single report (see the online help for more details),
  • step-by-step project execution,
  • application performance test,
  • regression test/automatic test.
By testing the project you can simulate how the application will run when launched from an executable. This allows you to test the entire application, even if it is still being developed. If a problem occurs, you can start the debugger to identify and fix the problem.
The window test is used to run the current window only. This allows you to test your project from a given window or to test a window once it has been finished. Like for the project test, the debugger can be started if a problem occurs.
The test of a single query runs the current query only. This allows you to check the operating mode of a query once it has been developed.
The test of a single report runs the current report only. This allows you to test a report once it has been developed. Like for the project test, the debugger can be started if a problem occurs.
The step-by-step project execution allows you to start the debugger when starting the application. This solution allows you to monitor the application progress.
The performance test checks and optimizes the execution time of your application.
The regression test (or automated test) is based on the execution of scripts. It checks that the existing features are still supported when running the applications.
In addition to these methods, WINDEV also provides a "Code coverage" tool to measure how many tests have been executed on your application. For more details, see the online help.
Testing and debugging a WINDEV project (development computer)

Overview

The test of the entire project allows you to simulate the start of the application with the executable. This allows you to test the entire application, even if it is still being developed. When a problem occurs during the execution of the project, you can start the debugger to identify and fix the problem.
WINDEV includes an extensive set of application tests that can be run from the development computer:
  • Test and debugging of the current project in the editor.
  • Execution and debugging of the executable corresponding to the current project.
  • Debugging of an executable already run on the development computer.
Remark: The test of a project can be run regardless of the current element in the editor.

Testing and debugging the current project

To test a project from the editor, go to the "Project" tab, expand "Test mode" and select "Debug project" (Ctrl + F9). The editor is automatically minimized and the project is run.

Testing and debugging the executable on the development computer

Some problems can only be reproduced when testing the executable in real-use conditions. This test mode allows you to debug an executable once it is installed on the development computer.
In this case, the code executed comes from the libraries (and not from the code in the elements on the computer). Therefore, the code from the current project and the code from the executable may be out-of-sync: the out-of-sync code is highlighted in pink during the debug operation.
This test mode is used to run a specific executable installed on the development computer and to debug it directly.
For more details, see the online help.

Debugging an executable already run on the development computer

Some problems can only be reproduced when testing the executable in real-use conditions.
This test mode allows you to find a problem that only occurs at runtime (and not in test mode).
The principle is simple:
  • The developer starts the executable on their computer and directly goes to the desired location in the application.
  • In WINDEV, the developer opens the project that correspond to the executable and establishes a connection with it.
  • The WINDEV debugger monitors the execution of the program step by step.
In this case, the code executed comes from the libraries (and not from the code in the elements on the computer). Therefore, the code from the current project and the code from the executable may be out-of-sync: the out-of-sync code is highlighted in pink during the debug operation.
For more details, see the online help.
Testing and debugging a WINDEV project on the user computer
WINDEV includes multiple methods to test and debug a project on the development computer. However, in some cases, you may have to debug directly on the end-user computer (connected over the network or via the Internet).
You can, for example, debug an application executed in Taiwan from your office in Paris. The debugging is performed remotely, directly on the user configuration.
Two features are available:
  • Running and debugging the executable on a remote computer,
  • Debugging an application currently running on a remote computer.
For these two features, a specific configuration of the remote computer is required.
Remark: to debug a WINDEV application remotely, the application must include the WD290CPL.DLL library in its framework.
For more details, see the online help.
Testing a window

Testing a window from the editor

To test a window from the editor:
  1. Open the window to be tested.
  2. Click in the quick access buttons (or press F9). The editor is automatically minimized and the window is run.
During the test, all window features can be run. You will be able to open other windows, for example.

Stopping the window test

There are multiple methods to stop the test:
  • 1st method:
    Close the application being tested. WINDEV goes back to editor that was open when the test was started.
  • 2nd method:
    • Go back to the editor via the taskbar or press Alt + Tab.
    • Stop the test. WINDEV goes back to editor that was open when the test was started.
Tracing a project

Debugging principles

Debugging an application consists in:
  • checking the operating mode of a process,
  • understanding the operating mode of an existing program,
  • checking the values of variables,
  • checking the operating mode of special cases in an application.
The debugger is used to perform these operations.
Remark: WINDEV also includes multiple trace tools (trace window, dialog box, etc.). For more details, see Debugging without debugger.

Debugger overview

The debugger monitors WLanguage programs so they can be improved.
The executed source code appears on the screen. The processes run are sorted in hierarchical order in the "Debugger" pane.
The value of the variables is displayed:
  • individually in the on-hover tooltip of each variable.
  • in the "Debugger" pane.

Debugger features

The debugger is used to:
  • view the call stack,
  • view the content of variables or expressions,
  • execute the code step by step with the possibility to skip code blocks,
  • use conditional breakpoints,
  • modify the code while continuing the execution,
  • etc.

Debugging without debugger

In some cases, running a program with or without debugger may be different. The debugger sets pauses in the execution of the processes, during which Windows performs multiple tasks. For example, the debugger cannot be used in a procedure called by a timer, nor in the code of a Scrollbar control.
Remark: For more details on the limitation of the debugger, see the online help.
To debug this type of applications, you may want to monitor the changes of a value, how different procedures are called, etc.
This information can be:
  • displayed on the screen.
  • stored in a trace file.
Caution: If the information is displayed on the screen, it must be displayed during the application tests only.
Displaying information
Two tools can be used to display information:
  • the dialog boxes: WLanguage Info function.
    Caution: When displayed, dialog boxes block the application.
  • the trace window: WLanguage Trace function.
    The trace window appears in the upper-left corner of the screen, without interrupting the program.
Displaying the debug information
Displaying the debug information on the screen is useful in test mode only.
Any unsuitable display must be removed before distributing an application.
To avoid any oversight, it is recommended to manage how the debug information is displayed via a global procedure. For example:
PROCEDURE MyTrace(StringToTrace)
IF InTestMode() = True THEN
Trace(StringToTrace)
END
In this code, depending on the result of InTestMode, the trace window appears during the application test only.
This procedure prevents trace windows from being displayed on end-user computers, even if they are called in the code of the application.
The call to this trace procedure is identical to the use of Trace:
MyTrace("Customer: "+ ...
Customer.CustomerNum)
Creating a trace file
During long processes (batch processing, etc.), to check the operating mode of the program, you must keep a physical trace of the processes run (a text file, for example).
The following procedure allows you to define how the trace will be displayed:
  • on the screen (/DEBUG parameter in command line).
  • in a text file (default mode).
    PROCEDURE MyTrace(StringToTrace)
    FilePath is string
    FilePath = fDataDirUser() + ProjectInfo(piProjectName) + ".txt"
    File is int
    DebugMode is boolean = False
    IF Position(CommandLine(), "/DEBUG") > 0 THEN
    DebugMode = True
    END

    IF DebugMode = True THEN
    Trace(StringToTrace)
    ELSE
    File = fOpen(FilePath, foCreateIfNotfound + foWrite + foAdd)
    IF File <> -1 THEN
    DateTimeTrace is DateTime
    DateTrace is Date
    TimeTrace is Time
    DateTimeTrace = SysDateTime()
    DateTrace = MyDate.Date
    TimeTrace = MyDate.Time
    fWriteLine(File, DateToString(DateTrace) + ...
     " - " + TimeToString(TimeTrace))
    fWriteLine(File, StringToTrace)
    fWriteLine(File, " ")
    fClose(File)
    END
    END
Remarks:
  • The trace file is created by default in the user data directory. The name of this file is the same as the project name. This file contains the information to trace during the program execution.
    The information is completed by the date and time of each "Trace". This allows you to detect a potential problem during the process.
  • Example of trace file content:
    01/12/2015 - 10:53:25:20
    Customer name: Montgomery
Performance test

Overview

The performance profiler checks and optimizes the execution time of the application.
The principle is straightforward: When you test your application, the performance profiler keeps track of all the actions performed and the corresponding processes executed.
At the end of the test, the performance profiler displays:
  • the 10 most time-consuming operations
  • all actions performed in the application that was tested, sorted by duration (from the longest to the shortest action).
You can select a process to analyze its processing time and optimize it.

Starting the performance profiler

To start the performance profiler, go to the "Project" tab, "Audit and performance" group, expand "Analyze performance" and select "Analyze performance".
The project is automatically run in test mode. The process to optimize can be run in your application.
To go back to the editor, simply close the application.
The performance profiler displays the result of the analysis.
Remark: It is recommended to use the performance profiler to optimize the application (before it is distributed, for example).

Reading the performance profiler results

The performance profiler presents the result of the analysis in several tabs:
  • the "Summary" tab shows the ten longest processes.
  • the "Mapping" tab shows a graphical view of the main processes.
  • the "Details" tab shows all the processes run during the test of the application (from the slowest to the fastest).
  • the "Calls" tab shows the details of the operations performed in a process.
The following information is displayed for each process:
FunctionFunction, event, process or procedure run.
Total timeFunction execution time.
Nb of callsNumber of calls made to the function (procedure, event or process).
Time 1 callExecution time of a call to the function (procedure, event or process).
code %Percentage of code run outside the call to a WLanguage function or outside the call to a custom function or procedure.
ParentProcess that called the function.

Remarks:
  • "Full execution" represents the total execution time of the application test in the performance profiler.
  • "Total for XXX Window" represents the total execution time of a given window (from the moment it is opened until closed).

Choosing a process to optimize

The processes to be optimized are chosen based on several criteria:
  • the process execution time. The longest processes must be optimized.
  • the percentage of time used by the function or procedure. The higher this percentage is, the greater the number of processes that can be optimized in the code.
Remark: If the process corresponds to a WLanguage function, it is fairly hard to optimize it.
Regression tests

Overview

Several test tools are available to guarantee the quality of your applications:
  • The test mode (Go on a project or window), which allows you to test changes in your application as you develop.
  • Automated tests to record a test scenario that can be easily re-played.
To automate these tests and increase the quality of your applications, you can create automated unit tests. These tests allow you to easily check all the features available in your applications.

Automated tests

Each test contains a scenario that can be directly edited in the development environment. This scenario is written in WLanguage and can be modified at any time.
These tests can be run before creating the executable to make sure the application runs properly.
The following elements can be tested:
  • WINDEV windows.
  • sets of procedures.
  • classes.
  • WINDEV executables.
Each test is associated with a WLanguage code: the test scenario. This scenario can be viewed in the code editor. The code of the tests can be modified.
The tests and their code are not included in the executable and are not provided to the end users. Therefore, the number of tests has no impact on the size of the application available to end users.
For more details, see the online help (keyword: "Automated test").
Previous pageTable of contentsNext page
Comments
Click [Add] to post a comment

Last update: 09/06/2022

Send a report | Local help