|
|
|
|
|
- Overview
- Running automated tests of an executable
- Method 1: Run automated executable tests from within WINDEV
- Method 2: Run automation tests on an executable without WINDEV
- Caution
- Command line
- Recording an automated test on an executable
- Recording with WD Automated Test
- Recording using a WX file
- Recording via the dbgStartRecording / dbgEndRecording functions
- "Automated test" event of the project
Automated tests on an executable
WINDEV includes WD Automated Test, an application that allows you to: - test a project using the corresponding executable. This makes it possible to test an executable under real deployment conditions.
- Record tests directly on an application.
Running automated tests of an executable The principle is straightforward: - An automated test tool (WDAutomate.exe) that uses its own framework allows you to run the desired executable.
- The executable to be tested must be in the end-user's conditions of use (with, if necessary, access to actual databases or an equivalent test database, the framework used, etc.).
- To run the different tests, the executable whose test must be run loads a specific library containing the tests:
- unit tests,
- application tests.
- Tests are run and the result is saved in the Control Centers. The result can be displayed:
- from the test controller (by selecting the executable and the test library).
- from WINDEV (for the project version with which the executable was created).
Note: The automation tests do not work on a non-interactive TSE session.. Method 1: Run automated executable tests from within WINDEV To directly run the automated tests on an executable from WINDEV: - Create the executable: pull down
from the quick access buttons and select "Generate Windows executable (32-bit)", for example. - Generate the test library: under the "Automated tests" pane, in the "Automated test" group, click on "Generate library".. The test library has the following format: TEST_<ProjectName>.WDL. This library is created in the "Data of automated tests" subdirectory of the project.
- Launch the test automaton, WDAutomate: under the "Automated tests" pane, in the "Automated test" group, click on "Start the automated test".. In this window, you must select:
- The relevant product (WINDEV).
- The executable whose test must be run.
- The test library to use.
- The command line (if necessary).
- The tests to run.
Note: If the executable contains internal components, the automation tests for these internal components also appear in the list of tests that can be run.
- Click "Run selected tests". Tests are automatically run and results displayed in the test controller.
Method 2: Run automation tests on an executable without WINDEV A WINDEV executable can be tested even if the corresponding application is not installed on the computer. However, some files are required: - Files required to start the test controller:
- WDAutomate.exe
- WDOutil.wdk
- wd300xx.dll
- wd300test.dll
- Files needed to record test results: Control Center data files. At least one Control Center must be installed on the computer.
The Control Center data files must be the same as the ones used on the development computer (to view the test results). Several cases may occur:- if the Control Centers use a Client/Server database, the data of the Control centers is shared between the computers.
- if the Control Centers use an HFSQL Classic database on a network, the Control Center data will be located in a shared directory.
- Executable to test with its framework (and the accesses required for the test).
- Test library and test data (the "Data of automated tests" subdirectory of the project must be copied to the computer)
The results of the automation tests can be consulted directly in WINDEV: simply open the project corresponding to the executable. Caution To test an executable created with a previous version of WINDEV, the test controller must have access to the WD300Test.DLL library that corresponds to the version of the executable. Therefore, the WD300Test.DLL library must be copied in the same location as WDAutomate.exe. Command line There are two syntax options to use WDAutomate in command line: - Syntax 1: Passing executable and test library directly:
WDAutomate [/EXE=<Name and path of the executable to be tested>] [/WDL=<Name and path of the automated test library>] - Syntax 2: Using a script file:
WDAutomate [/SCRIPT=<Script file path>] In this case, <Script file path> corresponds to a text file in XML format with the following content:
<?xml version="1.0"?>
<Script>
<EnsembleTest>
<EXE>Name and path of the executable to test</EXE>
<LC>Command line to pass to the executable</LC>
<WDL>Name and path of the automated test library</WDL>
</EnsembleTest>
</Script> The result of the scripts will be in a <Results> tag in the script file. The <Result> has the following format:
<Results>
<Test Nom="Valid test name" Passage="Attempt number" Result="OK"/>
<Test Nom="Invalid test name" Passage="Attempt number" Result="KO">
<Iteration Num="Iteration number">Error details</Iteration>
</Test>
</Results>
Recording an automated test on an executable Recording with WD Automated Test WD Automated Test allows you to record automated application tests. To record an application test with WD Automated Test: - Start WDAutomate: in the "Automated tests" pane, in the "Automated test" group, click on "Start the automated test".
- Select the executable you want to test. If necessary, specify the command line to be used.
- Select the "Record a new test" tab.
- Click "Launch application and record actions".
- The application launches: you can perform all the operations to be tested.
- When you close the application, WD Automated Test suggests saving a test scenario with all the actions performed. The default path is "C:\Users\nom_user\AppData\Roaming\PC SOFT\Nom_Appli\WDAutomate\scenarios\Scénario.wsct"..
This file can be opened in the test manager: - by dragging and dropping the file into the editor.
- or via the ribbon: under the "Automated tests" pane, in the "Tests" group, pull down "New" and select "Import a scenario saved in the application".
An "application tests" list containing the recorded scenario is created. You can rename the list of tests and the scenario. Recording using a WX file You can also start recording a test scenario using an entry in the application's .wx file. This scenario corresponds to an application test that can be opened in the test editor: - by dragging and dropping the file into the editor.
- or via the ribbon: under the "Automated tests" pane, in the "Tests" group, pull down "New" and select "Import a scenario saved in the application".
Reminder The .wx file must be used to set certain executable functions. It must have the same name as the .EXE file and be located in the same directory. Its extension is .wx (uppercase or lowercase characters). The following section must be added to the .wx file: [SCENARIO] ENABLED=1 FILE=<name and path of the test scenario file to record (the extension of this file must be .wsct)> DLLPATH=<path of the DLLs required to record the scenario> This method can be used if the executable does not use the same version of the DLLs as the test controller (WDAutomate.exe), which makes it impossible to store the two applications in the same directory. Two additional DLLs are required for test registration: wd300test.dll and wdtest.dll. Recording via the dbgStartRecording / dbgEndRecording functions This scenario corresponds to an application test that can be opened in the test editor: - by dragging and dropping the file into the editor.
- or via the ribbon: under the "Automated tests" pane, in the "Tests" group, pull down "New" and select "Import a scenario saved in the application".
"Automated test" event of the project WINDEV allows you to enable (or not) the "Automated test" event of the project. On the "Automated tests" tab, click  in the "Tests" group and select: - "Enable automated test code of the project".
- "Disable automated test code of the project".
In the case of an automated test, this event is run before the project initialization code. This code can be used to handle certain special cases where automatic testing may be blocked: opening a window in the project initialization code (parameter-setting window, license window, customized login window, etc.).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|