PC SOFT

WINDEVWEBDEV AND WINDEV MOBILE
ONLINE HELP

Home | Sign in | English UK
  • Overview
  • Running the test of a WINDEV project and debugging it (development computer)
  • Overview
  • Running the test of current project and debugging it
  • Running the executable and debugging it on the development computer
  • Debugging an executable that is already run on the development computer
  • Running the test of a WINDEV project and debugging it on the user computer
  • Running a window test
  • Running the window test from the editor
  • Stopping the window test
  • Tracing a project
  • Principles for debugging
  • Overview of debugger
  • Features of debugger
  • Debugging without debugger
  • Performance test
  • Overview
  • Starting the performance profiler
  • Reading the result of performance profiler
  • Choosing a process to optimize
  • Regression tests
  • Overview
  • Automatic tests
  • WDTest
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaReports and QueriesUser code (UMC)
WEBDEV
WindowsLinuxPHPWEBDEV - Browser code
WINDEV Mobile
AndroidAndroid Widget iPhone/iPadApple WatchUniversal Windows 10 AppWindows Mobile
Others
Stored procedures
16. Application test in practice
Previous pageTable of contentsNext page
Overview
WINDEV proposes several methods for running the test of your applications:
  • test of entire project,
  • test of single window,
  • test of single query (see the "Reports and Queries" guide for more details),
  • test of single report (see the "Reports and Queries" guide for more details),
  • step-by-step project execution,
  • test of performances of your application,
  • regression test/automatic test.
The test of entire project is used to simulate the application start by the executable. This allows you to run the test of entire application, even if its development is not finished yet. As soon as a problem occurs, you have the ability to start the debugger to identify and fix the problem.
The window test is used to run the current window only. This allows you to run the test of your project from a given window or to check the operating mode of a window as soon as its development is ended. Like for the project test, the debugger can be started as soon as a problem occurs.
The test of a single query is used to run the current query only. This allows you to check the operating mode of a query as soon as its development is ended.
The test of a single report is used to run the current report only. This allows you to check the implementation of a report as soon as it is developed. Like for the project test, the debugger can be started as soon as 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 test of application performances is used to check and optimize the execution time of your application.
The non-regression test (or automatic test) is based on the execution of scripts. It is used to check that the existing features are still supported when running your applications.
In addition to these different methods, WINDEV also proposes to find out the "Code coverage" of application, which means the measurement of coverage for the tests run on an application. See the online help for more details.
Running the test of a WINDEV project and debugging it (development computer)

Overview

The test of the entire WINDEV project is used to simulate the start of application by the executable. This allows you to run the test of entire application, even if its development is not finished yet. As soon as a problem occurs in the execution of the project, the debugger can be started to identify and fix the problem.
WINDEV proposes 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.
Note: The test of a project can be run regardless of the current element in the editor.

Running the test of current project and debugging it

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

Running the executable and debugging it on the development computer

Some problems can only be reproduced when running the executable test 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 run comes from the libraries (and not from the code found in the elements found on the computer). Therefore, the code of current project and the executable code may become 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.
See the online help for more details.

Debugging an executable that is already run on the development computer

Some problems can only be reproduced when running the test of the executable in real-use conditions.
This test mode allows you to find a problem that only occurs at run time (and not in test mode).
The principle is straightforward:
  • The developer starts the executable on his computer and directly goes to the requested location in the application.
  • In WINDEV, the developer opens the project corresponding to the executable and asks to be attached to the executable run.
  • The debugger in WINDEV is used to monitor the program execution step by step.
In this case, the code run comes from the libraries (and not from the code found in the elements found on the computer). Therefore, the code of current project and the executable code may become out-of-sync: the out-of-sync code is highlighted in pink during the debug operation.
See the online help for more details.
Running the test of a WINDEV project and debugging it on the user computer
WINDEV proposes several methods for running the test of a project and for debugging it on the development computer. However, in some cases, you may have to debug on the end-user computer (connected by network or by Internet).
From your office in London, you have the ability to debug an application that is run in Taiwan. The debug operation is performed without having to go anywhere, directly on the user configuration.
Two features are available:
  • Running and debugging the executable on a remote computer
  • Debugging an application that is currently run on a remote computer.
For these two features, a specific configuration is required for the remote computer.
Note: to debug a WINDEV application remotely, the application must include the WD240CPL.DLL library in its framework.
See the online help for more details.
Running a window test

Running the window test from the editor

To run the test of a window from the editor:
  1. Open the window whose test must be run.
  2. Click among 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 have the ability to open other windows for example.

Stopping the window test

Several methods can be used to stop the test:
  • 1st method:
    Close the application whose test is currently run. WINDEV displays the editor that was used at the beginning of test.
  • 2nd method:
    • Go back to the editor with the taskbar or press Alt + Tab.
    • Confirm that the test must be stopped. WINDEV displays the editor that was used at the beginning of test.
Tracing a project

Principles for debugging

Debugging an application consists in:
  • checking the operating mode of a process,
  • understanding the operating mode of an existing program,
  • checking the value of variables,
  • checking the operating mode of special cases in an application.
The debugger is used to perform these operations.
Note: WINDEV also includes several trace tools (trace window, information box, ...). See Debugging without debugger for more details.

Overview of debugger

The debugger is used to trace the WLanguage programs in order to help you improve these programs.
The source code run is viewed on the screen. The processes run are sorted in hierarchical order in the "Debugger" pane.
The value of variables can be viewed:
  • individually in the rollover tooltip of each variable.
  • in the "Debugger" pane.

Features of debugger

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

Debugging without debugger

In some cases, running a program with or without debugger may be different.
Indeed, the debugger introduces pauses in the execution of the process during which several tasks are performed by WINDEV.
Therefore, the debugger cannot be used in a procedure called by a timer or in the code of a scrollbar.
Note: See the online help for more details about the debugger limits.
To debug these applications, you may want to follow the evolution of a value, how different procedures are called, ...
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 information boxes: WLanguage Info function.
    Caution: Displaying an information box is a locking operation.
  • the trace window: WLanguage Trace function.
    The trace window is displayed in the top left corner of screen, without interrupting the program execution.
Managing the display of 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, we advise you to manage the display of debug information 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.
Such procedure allows you to leave the call to the trace windows in the application code without any risk of displaying it on the end-user computers.
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 processes, ...), to check the operating mode of program, you must keep a physical trace of processes run (a text file for example).
The following procedure is used to manage the trace display:
  • 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
Notes:
  • The trace file is created by default in the data directory of user. This file is named like the project. 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 content of trace file:
    01/12/2015 - 10:53:25:20
    Customer name: Montgomery
Performance test

Overview

The performance profiler is used to check and optimize the execution time of your application.
Its principle is straightforward:
You run the test of your application. During this test, the performance profiler keeps track of all the actions performed and the corresponding processes run.
At the end of test, the performance profiler displays:
  • the 10 most time consuming operations
  • all the actions performed in the application whose test was run, sorted by duration (from the longest one to the shortest one).
You can select a process in order to analyze the reasons for its processing time in order to optimize it.

Starting the performance profiler

To start the performance analyzer, on the "Project" pane, in the "Audit and performance" group, expand "Analyze the performance" and select "Analyze the 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, all you have to do is close your application.
Then, the performance profiler displays the result of the analysis.
Note: We recommend that you use the performance profiler to optimize your application (before it is distributed for example).

Reading the result of performance profiler

The performance profiler presents the result of the analysis in several tabs:
  • the "Summary" tab presents the ten longest processes.
  • the "Mapping" tab presents a graphical view of main processes.
  • the "Details" tab presents all processes run during the application test (from the slowest one to the fastest one).
  • the "Calls" tab is used to see the details of operations performed in a process.
The following information is displayed for each process:
FunctionFunction, process or procedure run.
Total TimeExecution time of function.
Nb of callsNumber of calls made to the function (procedure or process).
Time 1 callExecution time of a call to the function (procedure 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.

Notes:
  • The "Full execution" caption represents the total amount of time for running the application test with the performance profiler.
  • The "Total for XXX Window" caption represents the total amount of time for running the XXX window (from its opening to its closing).

Choosing a process to optimize

The process to optimize is chosen according to several criteria:
  • the execution time of process. The longest processes must necessarily be optimized.
  • the percentage of time spent in the process of function or procedure. The higher this percentage is, the greater the number of processes that can be optimized in the code.
Note: 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 Go on a window) is used to immediately check a modification in your application.
  • The automatic tests are used to save a test scenario that can be easily re-played.
  • WDTest that is used to create validation tests and regression tests in WINDEV.
To automate these tests and to increase the quality of your applications, you have the ability to run automatic unit tests. These tests are used to easily check all the features proposed by your applications.

Automatic tests

Each test contains a scenario that can be directly edited in the product interface. This scenario is written in WLanguage and it can be modified at any time.
These tests can be run before creating the executable in order to check the operating mode of an application.
The following elements can be checked:
  • the WINDEV windows.
  • the sets of procedures.
  • the classes.
  • the 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 the associated code are not included in the executable and they are not supplied to the end users. The number of tests for an application has no incidence on the size of the application supplied to the users.
See the online help for more details (keyword: "Automatic test").

WDTest

WDTest is a tool used to record and automatically run test scripts of applications (WINDEV or not).
A test script (also called "macro") mainly contains the different operations performed on an application (mouse movement, mouse click and keyboard input).
Once recorded, the test script can be run as many times as necessary. When a script is run, a result script is automatically generated. The differences found between the two scripts (source script and result script) are highlighted.
This feature allows you to check whether your WINDEV applications operate properly between two updates.
Therefore, WDTest is used to automate the test procedures of your applications.
Important: To run a test successfully, the same configuration must be used:
  • on the computer where the test is created.
  • on the computer where the test is run.
See the online help for more details (keyword: "WDTest").
Previous pageTable of contentsNext page
Minimum version required
  • Version 9
Comments
Click [Add] to post a comment