ONLINE HELP
 WINDEVWEBDEV AND WINDEV MOBILE

Help / WEBDEV concepts / Part 6 - Testing a website
  • Overview
  • Testing a WEBDEV project
  • Testing the project from the editor
  • Testing the project from the WEBDEV administrator
  • Stress test/Regression test
  • Testing a remote WEBDEV site (in AWP or Session mode)
  • Testing a page
  • Testing the page from the editor
  • Stopping the page test
  • Tracing a project
  • Debugging principles
  • Debugger overview
  • Debugger features
  • Debugging without the debugger
  • Performance test
  • Overview
  • Starting the performance profiler
  • Reading the performance profiler results
  • Choosing a process to optimize
  • Regression tests
  • Overview
  • Automated tests
  • WDTestSite
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
5. Site test in practice
Previous pageTable of contentsNext page
Overview
WEBDEV proposes several methods for running the test of your sites:
  • test of the entire project,
  • test of a single page,
  • test of a single query,
  • test of a single report,
  • step-by-step project execution,
  • site performance test,
  • regression test/automated test,
  • load test.
A test of the entire project simulates the site startup. This makes it possible to test the entire site, even if its development is not complete yet. If a problem occurs, you can start the debugger to identify and fix the problem.
A test of a single page runs the current page only. This allows you to test the project on a given page, or to test a page once its development is complete. Like for the project test, you can start the debugger 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, you can start the debugger if a problem occurs.
A step-by-step project execution allows you to launch the debugger when starting the site. This solution allows you to closely monitor how the site runs.
A performance test allows you to check and optimize the execution time of your site.
A regression test (or automated test) is based on the execution of scripts. It checks that existing features are still supported when the site is run.
A load test establishes multiple simultaneous connections to a dynamic WEBDEV site.
In addition to these methods, WEBDEV also includes the "Code coverage" of the site, i.e., the measurement of how much code is executed when the site is tested. For more details, see Code coverage.
Testing a WEBDEV project

Testing the project from the editor

Running the test from the editor allows you to test:
  • the site features,
  • the use of the site with different browsers.
The test of a project can be run regardless of the current element in the editor.
Remark: The test browser used to test the project can be selected:
  • in the WEBDEV options: on the "Home" tab, in the "Environment" group, expand "Options" and select "General options of WEBDEV". The browser can be selected in the "Web" tab.
  • in the test mode options: on the "Project" tab, in the "Test mode" group, expand "Test mode" and select "Test browser".
Different types of tests
To run the test of a static site from the editor:
  1. On the "Project" tab, in the "Test mode" group, expand "Test mode" and select "Debug project from the home page".
  2. The editor is automatically minimized.
  3. The browser specified in the WEBDEV options is opened and the site home page is displayed.
To run the test of a dynamic site (Session or AWP) from the editor, several methods are available:
  • On the "Project" tab, in the "Test mode" group, expand "Test mode" and select "Debug project" (or press Ctrl + F9).
  • Click in the quick access buttons.
The editor is automatically minimized, the browser specified in the WEBDEV options is opened and the first site page is displayed.
To test a static + dynamic site (Session or AWP) from the editor:
  • to test the static part of the site: perform the operations corresponding to the test of a static site.
  • to test the dynamic part of the site (Session or AWP): perform the operations corresponding to the test of a dynamic site.
Dynamic site (Session or AWP mode): Start
The following modules are automatically started during the test of a dynamic WEBDEV site (Session or AWP mode):
  • The Web server installed on the computer and configured for WEBDEV when installing WEBDEV.
    The test cannot be run if the Web server is not started.
  • The WEBDEV administrator (WD290ADMIN.EXE).
    The administrator is used to manage the connections to the Web server and to configure the WEBDEV sites.
    Remark: a project test can be run from the test page of the administrator ("Advanced" tab of WD290ADMIN, "Test page" button).
  • The WEBDEV engine (WD290AWP.EXE).
    The WEBDEV engine is used to manage the requests made by the Web users from their browser and to return the corresponding dynamic HTML page.
    Remark: The WEBDEV engine is started only if the project contains dynamic pages.
  • The Internet browser.
    The Internet browser displays the HTML pages of the WEBDEV site.

Testing the project from the WEBDEV administrator

Running the test from the WEBDEV administrator (WD290Admin) allows you to test:
  • the features of the site.
  • the features specific to the Web (use of cookies, etc).
Remark: The WEBDEV administrator can only be used to test dynamic sites (Session or AWP) or the dynamic part of static + dynamic sites.
Running the test from the WEBDEV administrator is equivalent to starting the dynamic site from a remote computer.
Before deploying a WEBDEV site, we recommend that you run the test of this site at least once from the WEBDEV administrator.
To run the test from the WEBDEV administrator:
  1. Start the WEBDEV administrator: on the "Tools" tab, in the "Web utilities" group, click "WDAdmin".
  2. In the "Advanced" tab of WEBDEV administrator, click the "Test page" button.
To stop the test, go to the WEBDEV administrator (click 2024 in the taskbar) and click "Disconnect" ("Connections" tab).
Remark: The WEBDEV administrator also allows you to run a project test equivalent to the project test run from the editor:
  1. Start the WEBDEV administrator: on the "Tools" tab, in the "Web utilities" group, click "WDAdmin".
  2. In the "Connection" tab, select the site and click the "Test" button.

Stress test/Regression test

WDTestSite runs load tests: WDTestSite is used to start several simultaneous connections to a dynamic WEBDEV site (Session or AWP).
Each connection performs a set of actions in the WEBDEV site (preset scenario).
For more details on WDTestSite, see WDTestSite.
Testing a remote WEBDEV site (in AWP or Session mode)
WEBDEV offers several methods to test and debug a site on the development computer. However, in some cases, you may have to debug the site directly on the user computers.
From your office in London, you have the ability to debug a site running on a Web server in Taiwan. The debug operation is done without having to go anywhere, on the final configuration directly.
Two features are available:
  • Starting and debugging the site on a remote application server.
  • Debugging a site currently used on a remote application server.
For these two features, a specific configuration of the remote computer is required.
Testing a page

Testing the page from the editor

To test a page from the editor:
  1. Open the page to be tested.
  2. Click in the quick access buttons of the WEBDEV menu. You can also press F9.
  3. The editor is automatically minimized and the page is run.
During the test, all page features can be run. You will be able to open other pages, for example.

Stopping the page test

There are multiple methods to stop the test:
  • 1st method:
    Close the page being tested. WEBDEV displays the editor open when the test was started.
  • 2nd method:
    • Go back to the editor via the taskbar or press Alt + Tab.
    • Stop the test. WEBDEV displays the editor 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 or in a site.
The debugger is used to perform these operations.
Remark: WEBDEV also includes several trace tools (trace window, information box, etc.). For more details, see "Debugging without the 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 allows you 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,
  • ...

Debugging without the 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.
Therefore, the debugger cannot be used in a procedure called by a timer or in the code of a scrollbar.
Remark: For more details on the limitation of the debugger, see the online help.
To debug these applications, you may want to follow the changes 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:
  • information 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() 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).
    PROCÉDURE MyTrace(StringToTrace)
    FilePath is int
    FilePath = fDataDirUser() + ...
    ProjectInfo(piProjectName) + ".txt"
    FileNum is int
    DebugMode is boolean = False
    IF Position(CommandLine(), "/DEBUG") > 0 THEN
    DebugMode = True
    END
    IF DebugMode THEN
    Trace(StringToTrace)
    ELSE
    FileNum = fOpen(FilePath, foCreateIfNotExist + ...
          foWrite + foAdd)
    IF FileNum <> -1 THEN
    DateTimeTrace is DateTime
    DateTimeTrace = SysDateTime()
    DateTrace is Date
    DateTrace = DateTimeTrace.Date
    TimeTrace is Time
    TimeTrace = DateTimeTrace.Time
    fWriteLine(FileNum, DateToString(DateTrace) + ...
    " - " + TimeToString(TimeTrace))
    fWriteLine(FileNum, StringToTrace)
    fWriteLine(FileNum, " ")
    fClose(FileNum)
    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: Martin
Performance test

Overview

The performance profiler allows you to check and optimize the execution time of your site.
The principle is straightforward:
  • The site test is executed.
  • During the test, the performance profiler keeps track of all the actions performed and the corresponding processes run.
At the end of the test, the performance profiler displays:
  • the 10 most time-consuming operations.
  • all the actions performed in the tested site, 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 site.
To go back to the editor, all you have to do is close your application or your site.
The performance profiler displays the result of the analysis.
Remark: The performance profiler should be used to optimize your site (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, process or procedure run.
Total timeFunction execution window.
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.

Remark:
  • The "Full execution" caption represents the total amount of time for running the site test with the performance profiler.
  • The "Total Page XXX" caption represents the total amount of time for running the page XXX (from its opening to its closing).

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 (project Go or page Go) is used to immediately check a modification performed in your site.
  • WDTestSite that is used to run different tests on a WEBDEV site.
To automate these tests and improve your applications, you can also run 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 each deployment in order to check the operating mode of a site after several modifications.
The following elements can be tested:
  • sets of procedures
  • classes
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 provided to the end users. Therefore, the number of tests has no impact on the size of the site available to end users.
For more details, see Automated tests.

WDTestSite

WDTestSite is used to run different tests on a WEBDEV site.
The following tests can be run by WDTestSite:
  • Load test:
    Load testing consists in simulating the connection of several users to a WEBDEV site. All users perform a series of operations (scenario) at the same time.
  • Regression test:
    Regression tests consist in checking how a WEBDEV site works between two updates. A scenario created with a previous version of the site must work correctly in the updated site.
  • Test of a site in multi-user mode:
    The test of a site in multi-user mode checks whether concurrent accesses to the data files are handled properly. This test consists in simulating the simultaneous connection of several users to a WEBDEV site. All users perform a series of operations (scenario) at the same time.
  • Comparison of different servers:
    WDTestSite is used to compare the speed of different servers. To do so, run the same scenario on different servers and compare the execution time of this scenario.
  • Optimization of processes developed in WLanguage:
    WDTestSite is used to compare the execution time of a scenario before and after the WLanguage code was optimized.
For more details, see WDTestSite.
Previous pageTable of contentsNext page
Comments
Click [Add] to post a comment

Last update: 08/29/2023

Send a report | Local help