- Running the test of WEBDEV project
- Running the project test from the editor
- Running the project test from the WEBDEV administrator
- Stress test/Regression test
- Testing a remote WEBDEV site (in AWP or Session mode)
- Running the page test
- Running the page test from the editor
- Stopping the page test
- Tracing a project
- Principles for debugging
- Overview of debugger
- Features of debugger
- Debugging without debugger
- Performance test
- Starting the performance profiler
- Reading the result of performance profiler
- Choosing a process to optimize
- Regression tests
- Automatic tests
5. Test of a site in practice
WEBDEV offers several methods for testing your sites:
- test of the entire project,
- test of a single page,
- test of a single query (see the "Reports & Queries" guide for more details),
- test of a single report (see the "Reports & Queries" guide for more details),
- step-by-step project execution,
- test of performance of your site,
- regression test/automatic test,
- stress test.
The test of the entire project is used to simulate the startup of the site. This allows you to run test of entire site, 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 test of a single page is used to run the current page only. This allows you to run the test of your project from a given page or to check the operating mode of a page as soon as its development has 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.
Running the project step by step is used to launch the debugger when starting the site. This solution allows you to closely monitor how the site runs.
The performance test of your site allows you to check and optimize its execution time.
The non-regression test (or automatic test) is based on the execution of scripts. It allows you to check that, during the execution of your site, ... the existing features are still supported.
The stress test is used to start several simultaneous connections to the same dynamic WEBDEV site.
In addition to these methods, WEBDEV also proposes to find out the "Code coverage" of site, which means the coverage measurement for the tests run on a site. For more details, see Code coverage
Running the test of WEBDEV project
Running the project test 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 run the project test can be chosen:
- in the WEBDEV options: on the "Home" pane, in the "Environment" group, expand "Options" and select "General options of WEBDEV". The browser can be selected in the "Web" tab.
- in the options of test mode: on the "Project" pane, 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:
- On the "Project" pane, in the "Test mode" group, expand "Test mode" and select "Debug project from the home page".
- The editor is automatically minimized.
- 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" pane, in the "Test mode" group, expand "Test mode" and select "Debug project" (or press Ctrl + F9).
- Click among 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 (WD260ADMIN.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 WD260ADMIN, "Test page" button).
- The WEBDEV engine (WD260AWP.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 is used to display the HTML pages of the WEBDEV site.
Running the project test from the WEBDEV administrator
Running the test from the WEBDEV administrator (WD260Admin) allows you to test:
- the features of the site.
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:
To stop the test
- Start the WEBDEV administrator: on the "Tools" pane, in the "Web utilities" group, click "WDAdmin".
- In the "Advanced" tab of WEBDEV administrator, click the "Test page" button.
, display the WEBDEV administrator (click the icon 26 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:
- Start the WEBDEV administrator: on the "Tools" pane, in the "Web utilities" group, click "WDAdmin".
- In the "Connection" tab, select the site and click the "Test" button.
Stress test/Regression test
WDTestSite is used to run stress 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).
Testing a remote WEBDEV site (in AWP or Session mode)
Several methods can be used to run a test and to 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 is required for the remote computer.
Running the page test from the editor
To run the test of a page from the editor
- Open the page to be tested.
- Click among the quick access buttons of WEBDEV menu. You can also use the F9 key.
- The editor is automatically minimized and the page is run.
During the test, all page features can be run. You will have the ability to open other pages for example.
Stopping the page test
Several methods can be used to stop the test:
- 1st method:
Close the page being tested. WEBDEV 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. WEBDEV displays the editor that was used at the beginning of test.
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 or in a site.
The debugger is used to perform these operations.
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 on-hover 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.
Remark: 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.
Two tools can be used to display information:
- information boxes: Info WLanguage function.
Caution: Displaying an information box is a locking operation.
- the trace window: Trace WLanguage 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.
IF InTestMode() THEN
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
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).
FilePath is int
FilePath = fDataDirUser() + ProjectInfo(piProjectName)+ ".txt"
FileNum is int
DebugMode is boolean = False
IF Position(CommandLine(), "/DEBUG") > 0 THEN
DebugMode = True
IF DebugMode THEN
FileNum = fOpen(FilePath, foCreateIfNotExist + ...
foWrite + foAdd)
If FileNum <> -1 THEN
DateTimeTrace is DateTime
DateTimeTrace = SysDateTime()
DateTrace is Date
DateTrace = MyDate..Date
TimeTrace is Time
TimeTrace = MyDate..Time
fWriteLine(FileNum, DateToString(DateTrace) + ...
" - "+TimeToString(TimeTrace))
fWriteLine(FileNum, " ")
- 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
The performance profiler allows you to check and optimize the execution time of your site.
Its principle is straightforward:
- You run the test of your site.
- 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 tested site, sorted by duration (from the longest to the shortest action).
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 profiler, go to the "Project" pane, "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.
Then, 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 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:
|Function||Function, process or procedure run.|
|Total Time||Execution time of function.|
|Nb of calls||Number of calls made to the function (procedure or process).|
|Time 1 call||Execution 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.|
|Parent||Process that called the function.|
- 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 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.
: If the process corresponds to a WLanguage function, it is fairly hard to optimize it.
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 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.
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 each deployment in order to check the operating mode of a site after several modifications.
The following elements can be checked:
- the sets of procedures
- the 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 distributed to the end users. Therefore, the number of tests for a site has no incidence on the size of site supplied to the end users.
WDTestSite is used to run different tests on a WEBDEV site.
The following tests can be run by WDTestSite:
- Stress test:
The stress test consists in simulating the connection of several Web users to a WEBDEV site. Each Web user runs a set of operations (scenario) simultaneously.
- Regression test:
The regression test consists in checking the operating mode of a WEBDEV site between two updates. The regression test consists in checking whether a scenario performed with an earlier site version still operates properly once the site was updated.
- Test of a site in multi-user mode:
The test of a site in multi-user mode is used to check whether concurrent accesses to the data files are managed properly. This test consists in simulating the simultaneous connection of several Web users to a WEBDEV site. Each Web user runs a set of operations (scenario) simultaneously.
- 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.
Click [Add] to post a comment