Correction of test-cases according to OCC23150 requirements (new format of checknbsha...
[occt.git] / dox / dev_guides / tests / tests.md
CommitLineData
ba06f8bb 1 Automated Testing System {#occt_dev_guides__tests}
72b7576f 2======================================
3
e5bd0d98 4@tableofcontents
5
72b7576f 6@section testmanual_1 Introduction
7
504a8968 8This document provides OCCT developers and contributors with an overview and practical guidelines for work with OCCT automatic testing system.
9
10Reading the Introduction is sufficient for OCCT developers to use the test system to control non-regression of the modifications they implement in OCCT. Other sections provide a more in-depth description of the test system, required for modifying the tests and adding new test cases.
72b7576f 11
12@subsection testmanual_1_1 Basic Information
13
ba06f8bb 14OCCT automatic testing system is organized around DRAW Test Harness @ref occt_user_guides__test_harness "DRAW Test Harness", a console application based on Tcl (a scripting language) interpreter extended by OCCT-related commands.
e5bd0d98 15
504a8968 16Standard OCCT tests are included with OCCT sources and are located in subdirectory *tests* of the OCCT root folder. Other test folders can be included in the test system, e.g. for testing applications based on OCCT.
e5bd0d98 17
504a8968 18The tests are organized in three levels:
72b7576f 19
504a8968 20 * Group: a group of related test grids, usually testing a particular OCCT functionality (e.g. blend);
21 * Grid: a set of test cases within a group, usually aimed at testing some particular aspect or mode of execution of the relevant functionality (e.g. buildevol);
22 * Test case: a script implementing an individual test (e.g. K4).
23
24See <a href="#testmanual_5_1">Test Groups</a> for the current list of available test groups and grids.
72b7576f 25
936f43da 26Some tests involve data files (typically CAD models) which are located separately and are not included with OCCT code. The archive with publicly available test data files should be downloaded and installed independently on OCCT sources (see http://dev.opencascade.org).
72b7576f 27
28@subsection testmanual_1_2 Intended Use of Automatic Tests
29
30Each modification made in OCCT code must be checked for non-regression
31by running the whole set of tests. The developer who does the modification
504a8968 32is responsible for running and ensuring non-regression for the tests available to him.
33
34Note that many tests are based on data files that are confidential and thus available only at OPEN CASCADE. Thus official certification testing of the changes before integration to master branch of official OCCT Git repository (and finally to the official release) is performed by OPEN CASCADE in any case.
35
36Each new non-trivial modification (improvement, bug fix, new feature) in OCCT should be accompanied by a relevant test case suitable for verifying that modification. This test case is to be added by the developer who provides the modification.
72b7576f 37
504a8968 38If a modification affects the result of an existing test case, either the modification should be corrected (if it causes regression) or the affected test cases should be updated to account for the modification.
72b7576f 39
504a8968 40The modifications made in the OCCT code and related test scripts should be included in the same integration to the master branch.
72b7576f 41
42@subsection testmanual_1_3 Quick Start
43
44@subsubsection testmanual_1_3_1 Setup
45
504a8968 46Before running tests, make sure to define environment variable *CSF_TestDataPath* pointing to the directory containing test data files.
504a8968 47
48For this it is recommended to add a file *DrawAppliInit* in the directory which is current at the moment of starting DRAWEXE (normally it is OCCT root directory, <i>$CASROOT </i>). This file is evaluated automatically at the DRAW start.
49
50Example (Windows)
72b7576f 51
52~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
504a8968 53set env(CSF_TestDataPath) $env(CSF_TestDataPath)\;d:/occt/test-data
72b7576f 54return ;# this is to avoid an echo of the last command above in cout
504a8968 55
72b7576f 56~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
504a8968 57Note that variable *CSF_TestDataPath* is set to default value at DRAW start, pointing at the folder <i>$CASROOT/data</i>.
87f42a3f 58In this example, subdirectory <i>d:/occt/test-data</i> is added to this path. Similar code could be used on Linux and Mac OS X except that on non-Windows platforms colon ":" should be used as path separator instead of semicolon ";".
72b7576f 59
936f43da 60All tests are run from DRAW command prompt (run *draw.bat* or *draw.sh* to start it).
72b7576f 61
62@subsubsection testmanual_1_3_2 Running Tests
63
504a8968 64To run all tests, type command *testgrid*
72b7576f 65
66Example:
67
504a8968 68~~~~~
69Draw[]> testgrid
70~~~~~
72b7576f 71
87f42a3f 72For running only a subset of test cases, give masks for group, grid, and test case names to be executed.
73Each argument is a list of comma- or space-separated file masks; by default "*" is assumed.
72b7576f 74
504a8968 75Example:
72b7576f 76
504a8968 77~~~~~
87f42a3f 78Draw[]> testgrid bugs caf,moddata*,xde
504a8968 79~~~~~
72b7576f 80
72b7576f 81
82As the tests progress, the result of each test case is reported.
504a8968 83At the end of the log a summary of test cases is output,
84including the list of detected regressions and improvements, if any.
72b7576f 85
86
504a8968 87Example:
88
72b7576f 89~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
90 Tests summary
91
92 CASE 3rdparty export A1: OK
93 ...
94 CASE pipe standard B1: BAD (known problem)
95 CASE pipe standard C1: OK
96 No regressions
97 Total cases: 208 BAD, 31 SKIPPED, 3 IMPROVEMENT, 1791 OK
98 Elapsed time: 1 Hours 14 Minutes 33.7384512019 Seconds
99 Detailed logs are saved in D:/occt/results_2012-06-04T0919
100~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
101
504a8968 102The tests are considered as non-regressive if only OK, BAD (i.e. known problem), and SKIPPED (i.e. not executed, typically because of lack of a data file) statuses are reported. See <a href="#testmanual_3_5">Interpretation of test results</a> for details.
72b7576f 103
936f43da 104The results and detailed logs of the tests are saved by default to a new subdirectory of the subdirectory *results* in the current folder, whose name is generated automatically using the current date and time, prefixed by Git branch name (if Git is available and current sources are managed by Git).
504a8968 105If necessary, a non-default output directory can be specified using option <i> –outdir</i> followed by a path to the directory. This directory should be new or empty; use option –overwrite to allow writing results in existing non-empty directory.
72b7576f 106
504a8968 107Example:
108~~~~~
87f42a3f 109Draw[]> testgrid -outdir d:/occt/last_results -overwrite
504a8968 110~~~~~
111In the output directory, a cumulative HTML report summary.html provides links to reports on each test case. An additional report in JUnit-style XML format can be output for use in Jenkins or other continuous integration system.
112
936f43da 113Type <i>help testgrid</i> in DRAW prompt to get help on options supported by *testgrid* command:
72b7576f 114
504a8968 115~~~~~
116Draw[3]> help testgrid
117testgrid: Run all tests, or specified group, or one grid
87f42a3f 118 Use: testgrid [groupmask [gridmask [casemask]]] [options...]
504a8968 119 Allowed options are:
120 -parallel N: run N parallel processes (default is number of CPUs, 0 to disable)
121 -refresh N: save summary logs every N seconds (default 60, minimal 1, 0 to disable)
122 -outdir dirname: set log directory (should be empty or non-existing)
123 -overwrite: force writing logs in existing non-empty directory
124 -xml filename: write XML report for Jenkins (in JUnit-like format)
936f43da 125 -beep: play sound signal at the end of the tests
87f42a3f 126 Groups, grids, and test cases to be executed can be specified by list of file
127 masks, separated by spaces or comma; default is all (*).
504a8968 128~~~~~
72b7576f 129
504a8968 130@subsubsection testmanual_1_3_3 Running a Single Test
131
87f42a3f 132To run a single test, type command *test* followed by names of group, grid, and test case.
72b7576f 133
134Example:
135
136~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
137 Draw[1]> test blend simple A1
138 CASE blend simple A1: OK
139 Draw[2]>
140~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
141
504a8968 142Note that normally an intermediate output of the script is not shown. The detailed log of the test can be obtained after the test execution by running command <i>"dlog get"</i>.
143
144To see intermediate commands and their output during the test execution, add one more argument
145<i>"echo"</i> at the end of the command line. Note that with this option the log is not collected and summary is not produced.
146
936f43da 147Type <i>help testgrid</i> in DRAW prompt to get help on options supported by *testgrid* command:
148
149~~~~~
150Draw[3]> help test
151test: Run specified test case
152 Use: test group grid casename [options...]
153 Allowed options are:
154 -echo: all commands and results are echoed immediately,
155 but log is not saved and summary is not produced
156 It is also possible to use "1" instead of "-echo"
157 If echo is OFF, log is stored in memory and only summary
158 is output (the log can be obtained with command "dlog get")
159 -outfile filename: set log file (should be non-existing),
160 it is possible to save log file in text file or
161 in html file(with snapshot), for that "filename"
162 should have ".html" extension
163 -overwrite: force writing log in existing file
164 -beep: play sound signal at the end of the test
165 -errors: show all lines from the log report that are recognized as errors
166 This key will be ignored if the "-echo" key is already set.
167~~~~~
168
504a8968 169@subsubsection testmanual_1_3_4 Creating a New Test
170
171The detailed rules of creation of new tests are given in <a href="#testmanual_3">section 3</a>. The following short description covers the most typical situations:
172
87f42a3f 173Use prefix "bug" followed by Mantis issue ID and, if necessary, additional suffixes, for naming the test script and DRAW commands specific for this test case.
504a8968 174
1751. If the test requires C++ code, add it as new DRAW command(s) in one of files in *QABugs* package. Note that this package defines macros *QVERIFY* and *QCOMPARE*, thus code created for QTest or GoogleTest frameworks can be used with minimal modifications.
1762. Add script(s) for the test case in grid (subfolder) corresponding to the relevant OCCT module of the group bugs <i>($CASROOT/tests/bugs)</i>. See <a href="#testmanual_5_2">the correspondence map</a>.
1773. In the test script:
178 * Load all necessary DRAW modules by command *pload*.
179 * Use command *locate_data_file* to get a path to data files used by test script. (Make sure to have this command not inside catch statement if it is used.)
180 * Use DRAW commands to reproduce the situation being tested.
181 * If test case is added to describe existing problem and the fix is not available, add TODO message for each error to mark it as known problem. The TODO statements must be specific so as to match the actually generated messages but not all similar errors.
87f42a3f 182 * Make sure that in case of failure the test produces message containing word "Error" or other recognized by test system as error (see files parse.rules).
504a8968 1834. If the test case uses data file(s) not yet present in the test database, these can be put to subfolder data of the test grid, and integrated to Git along with the test case.
1845. Check that the test case runs as expected (test for fix: OK with the fix, FAILED without the fix; test for existing problem: BAD), and integrate to Git branch created for the issue.
185
186Example:
187
188* Added files:
936f43da 189
504a8968 190~~~~~
191git status –short
192A tests/bugs/heal/data/OCC210a.brep
193A tests/bugs/heal/data/OCC210a.brep
194A tests/bugs/heal/bug210_1
195A tests/bugs/heal/bug210_2
196~~~~~
197
198* Test script
199
200~~~~~
201puts "OCC210 (case 1): Improve FixShape for touching wires"
202
203restore [locate_data_file OCC210a.brep] a
204
205fixshape result a 0.01 0.01
206checkshape result
207~~~~~
72b7576f 208
209@section testmanual_2 Organization of Test Scripts
210
211@subsection testmanual_2_1 General Layout
212
213Standard OCCT tests are located in subdirectory tests of the OCCT root folder ($CASROOT).
72b7576f 214
504a8968 215Additional test folders can be added to the test system by defining environment variable *CSF_TestScriptsPath*. This should be list of paths separated by semicolons (*;*) on Windows
216or colons (*:*) on Linux or Mac. Upon DRAW launch, path to tests sub-folder of OCCT is added at the end of this variable automatically.
217
218Each test folder is expected to contain:
72b7576f 219 * Optional file parse.rules defining patterns for interpretation of test results, common for all groups in this folder
220 * One or several test group directories.
221
222Each group directory contains:
223
504a8968 224 * File *grids.list* that identifies this test group and defines list of test grids in it.
225 * Test grids (sub-directories), each containing set of scripts for test cases, and optional files *cases.list*, *parse.rules*, *begin* and *end*.
72b7576f 226 * Optional sub-directory data
72b7576f 227
504a8968 228By convention, names of test groups, grids, and cases should contain no spaces and be lower-case.
229The names *begin, end, data, parse.rules, grids.list* and *cases.list* are reserved.
72b7576f 230
504a8968 231General layout of test scripts is shown in Figure 1.
232
233@image html /dev_guides/tests/images/tests_image001.png "Layout of tests folder"
234@image latex /dev_guides/tests/images/tests_image001.png "Layout of tests folder"
72b7576f 235
72b7576f 236
237@subsection testmanual_2_2 Test Groups
238
239@subsubsection testmanual_2_2_1 Group Names
240
504a8968 241The names of directories of test groups containing systematic test grids correspond to the functionality tested by each group.
242
72b7576f 243Example:
244
504a8968 245~~~~~
72b7576f 246 caf
247 mesh
248 offset
504a8968 249~~~~~
72b7576f 250
504a8968 251Test group *bugs* is used to collect the tests coming from bug reports. Group *demo* collects tests of the test system, DRAW, samples, etc.
72b7576f 252
504a8968 253@subsubsection testmanual_2_2_2 File "grids.list"
254
255This test group contains file *grids.list*, which defines an ordered list of grids in this group in the following format:
72b7576f 256
257~~~~~~~~~~~~~~~~~
258001 gridname1
259002 gridname2
260...
261NNN gridnameN
262~~~~~~~~~~~~~~~~~
263
264Example:
265
266~~~~~~~~~~~~~~~~~
267 001 basic
268 002 advanced
269~~~~~~~~~~~~~~~~~
270
504a8968 271@subsubsection testmanual_2_2_3 File "begin"
72b7576f 272
504a8968 273This file is a Tcl script. It is executed before every test in the current group.
72b7576f 274Usually it loads necessary Draw commands, sets common parameters and defines
275additional Tcl functions used in test scripts.
504a8968 276
72b7576f 277Example:
278
279~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
280 pload TOPTEST ;# load topological command
281 set cpulimit 300 ;# set maximum time allowed for script execution
282~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
283
504a8968 284@subsubsection testmanual_2_2_4 File "end"
72b7576f 285
504a8968 286This file is a TCL script. It is executed after every test in the current group. Usually it checks the results of script work, makes a snap-shot of the viewer and writes *TEST COMPLETED* to the output.
72b7576f 287
504a8968 288Note: *TEST COMPLETED* string should be present in the output to indicate that the test is finished without crash.
289
290See <a href="#testmanual_3">section 3</a> for more information.
291
292Example:
293~~~~~
72b7576f 294 if { [isdraw result] } {
295 checkshape result
296 } else {
4ee1bdf4 297 puts "Error: The result shape can not be built"
72b7576f 298 }
4ee1bdf4 299 puts "TEST COMPLETED"
504a8968 300~~~~~
301
302@subsubsection testmanual_2_2_5 File "parse.rules"
303
304The test group may contain *parse.rules* file. This file defines patterns used for analysis of the test execution log and deciding the status of the test run.
305
306Each line in the file should specify a status (single word), followed by a regular expression delimited by slashes (*/*) that will be matched against lines in the test output log to check if it corresponds to this status.
307
936f43da 308The regular expressions support a subset of the Perl *re* syntax. See also <a href="http://perldoc.perl.org/perlre.html">Perl regular expressions</a>.
504a8968 309
310The rest of the line can contain a comment message, which will be added to the test report when this status is detected.
72b7576f 311
72b7576f 312Example:
313
504a8968 314~~~~~
e5bd0d98 315 FAILED /\\b[Ee]xception\\b/ exception
316 FAILED /\\bError\\b/ error
72b7576f 317 SKIPPED /Cannot open file for reading/ data file is missing
318 SKIPPED /Could not read file .*, abandon/ data file is missing
504a8968 319~~~~~
72b7576f 320
321Lines starting with a *#* character and blank lines are ignored to allow comments and spacing.
72b7576f 322
504a8968 323See <a href="#testmanual_3_5">Interpretation of test results</a> chapter for details.
324
325If a line matches several rules, the first one applies. Rules defined in the grid are checked first, then rules in the group, then rules in the test root directory. This allows defining some rules on the grid level with status *IGNORE* to ignore messages that would otherwise be treated as errors due to the group level rules.
326
72b7576f 327Example:
328
329~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
e5bd0d98 330 FAILED /\\bFaulty\\b/ bad shape
72b7576f 331 IGNORE /^Error [23]d = [\d.-]+/ debug output of blend command
332 IGNORE /^Tcl Exception: tolerance ang : [\d.-]+/ blend failure
333~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
334
504a8968 335@subsubsection testmanual_2_2_6 Directory "data"
336The test group may contain subdirectory *data*, where test scripts shared by different test grids can be put. See also <a href="#testmanual_2_3_5">Directory *data*</a>.
337
72b7576f 338@subsection testmanual_2_3 Test Grids
339
340@subsubsection testmanual_2_3_1 Grid Names
341
504a8968 342The folder of a test group can have several sub-directories (Grid 1… Grid N) defining test grids.
343Each directory contains a set of related test cases. The name of a directory should correspond to its contents.
72b7576f 344
345Example:
346
504a8968 347~~~~~
72b7576f 348caf
349 basic
350 bugs
351 presentation
504a8968 352~~~~~
72b7576f 353
504a8968 354Here *caf* is the name of the test group and *basic*, *bugs*, *presentation*, etc. are the names of grids.
72b7576f 355
504a8968 356@subsubsection testmanual_2_3_2 File "begin"
357
358This file is a TCL script executed before every test in the current grid.
72b7576f 359
72b7576f 360Usually it sets variables specific for the current grid.
504a8968 361
72b7576f 362Example:
363
364~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
365 set command bopfuse ;# command tested in this grid
366~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
367
504a8968 368@subsubsection testmanual_2_3_3 File "end"
369
370This file is a TCL script executed after every test in current grid.
371
372Usually it executes a specific sequence of commands common for all tests in the grid.
72b7576f 373
72b7576f 374Example:
375
376~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
936f43da 377 vdump $imagedir/${casename}.png ;# makes a snap-shot of AIS viewer
72b7576f 378~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
379
504a8968 380@subsubsection testmanual_2_3_4 File "cases.list"
72b7576f 381
382The grid directory can contain an optional file cases.list
504a8968 383defining an alternative location of the test cases.
384This file should contain a single line defining the relative path to the collection of test cases.
72b7576f 385
386Example:
387
504a8968 388~~~~~
72b7576f 389../data/simple
504a8968 390~~~~~
391
392This option is used for creation of several grids of tests with the same data files and operations but performed with differing parameters. The common scripts are usually located place in the common
393subdirectory of the test group, <i>data/simple</i> for example.
72b7576f 394
504a8968 395If file *cases.list* exists, the grid directory should not contain any test cases.
72b7576f 396The specific parameters and pre- and post-processing commands
504a8968 397for test execution in this grid should be defined in the files *begin* and *end*.
398
399
400@subsubsection testmanual_2_3_5 Directory "data"
401
402The test grid may contain subdirectory *data*, containing data files used in tests (BREP, IGES, STEP, etc.) of this grid.
72b7576f 403
404@subsection testmanual_2_4 Test Cases
405
504a8968 406The test case is a TCL script, which performs some operations using DRAW commands
407and produces meaningful messages that can be used to check the validity of the result.
408
72b7576f 409Example:
410
411~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
412 pcylinder c1 10 20 ;# create first cylinder
413 pcylinder c2 5 20 ;# create second cylinder
414 ttranslate c2 5 0 10 ;# translate second cylinder to x,y,z
415 bsection result c1 c2 ;# create a section of two cylinders
416 checksection result ;# will output error message if result is bad
417~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
418
504a8968 419The test case can have any name (except for the reserved names *begin, end, data, cases.list* and *parse.rules*).
72b7576f 420For systematic grids it is usually a capital English letter followed by a number.
421
422Example:
423
504a8968 424~~~~~
72b7576f 425 A1
426 A2
427 B1
428 B2
504a8968 429~~~~~
72b7576f 430
504a8968 431Such naming facilitates compact representation of tests execution results in tabular format within HTML reports.
72b7576f 432
72b7576f 433
434@section testmanual_3 Creation And Modification Of Tests
435
436This section describes how to add new tests and update existing ones.
437
438@subsection testmanual_3_1 Choosing Group, Grid, and Test Case Name
439
504a8968 440The new tests are usually added in the frame of processing issues in OCCT Mantis tracker.
72b7576f 441Such tests in general should be added to group bugs, in the grid
504a8968 442corresponding to the affected OCCT functionality. See <a href="#testmanual_5_2">Mapping of OCCT functionality to grid names in group *bugs*</a>.
443
444New grids can be added as necessary to contain tests for the functionality not yet covered by existing test grids.
445The test case name in the bugs group should be prefixed by the ID of the corresponding issue in Mantis (without leading zeroes) with prefix *bug*. It is recommended to add a suffix providing a hint on the tested situation. If more than one test is added for a bug, they should be distinguished by suffixes; either meaningful or just ordinal numbers.
72b7576f 446
447Example:
448
449~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
504a8968 450 bug12345_coaxial
451 bug12345_orthogonal_1
452 bug12345_orthogonal_2
72b7576f 453~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
454
504a8968 455If the new test corresponds to a functionality already covered by the existing systematic test grid (e.g. group *mesh* for *BRepMesh* issues), this test can be added (or moved later by OCC team) to that grid.
72b7576f 456
457@subsection testmanual_3_2 Adding Data Files Required for a Test
458
504a8968 459It is advisable to make self-contained test scripts whenever possible, so as they could be used in environments where data files are not available. For that simple geometric objects and shapes can be created using DRAW commands in the test script itself.
460
936f43da 461If the test requires a data file, it should be put to directory listed in environment variable *CSF_TestDataPath*.
462Alternatively, it can be put to subdirectory *data* of the test grid.
463It is recommended to prefix the data file with the corresponding issue id prefixed by *bug*, e.g. *bug12345_face1.brep*, to avoid possible conflicts with names of existing data files.
504a8968 464
465Note that when the test is integrated to the master branch, OCC team will move the data file to data files repository, so as to keep OCCT sources repository clean from data files.
466
467When preparing a test script, try to minimize the size of involved data model. For instance, if the problem detected on a big shape can be reproduced on a single face extracted from that shape, use only that face in the test.
468
469
470@subsection testmanual_3_3 Adding new DRAW commands
471
472If the test cannot be implemented using available DRAW commands, consider the following possibilities:
473* If the existing DRAW command can be extended to enable possibility required for a test in a natural way (e.g. by adding an option to activate a specific mode of the algorithm), this way is recommended. This change should be appropriately documented in a relevant Mantis issue.
474* If the new command is needed to access OCCT functionality not exposed to DRAW previously, and this command can be potentially reused (for other tests), it should be added to the package where similar commands are implemented (use *getsource* DRAW command to get the package name). The name and arguments of the new command should be chosen to keep similarity with the existing commands. This change should be documented in a relevant Mantis issue.
475* Otherwise the new command implementing the actions needed for this particular test should be added in *QABugs* package. The command name should be formed by the Mantis issue ID prefixed by *bug*, e.g. *bug12345*.
476
477Note that a DRAW command is expected to return 0 in case of a normal completion, and 1 (Tcl exception) if it is incorrectly used (e.g. a wrong number of input arguments). Thus if the new command needs to report a test error, this should be done by outputting an appropriate error message rather than by returning a non-zero value.
7a7e8cf1 478Also file names must not be encoded in DRAW command but in script, and passed to DRAW command as argument.
504a8968 479
480@subsection testmanual_3_4 Script Implementation
481
482The test should run commands necessary to perform the tested operations, in general assuming a clean DRAW session. The required DRAW modules should be loaded by *pload* command, if it is not done by *begin* script. The messages produced by commands in a standard output should include identifiable messages on the discovered problems if any.
483
484Usually the script represents a set of commands that a person would run interactively to perform the operation and see its results, with additional comments to explain what happens.
485
72b7576f 486Example:
504a8968 487~~~~~
488# Simple test of fusing box and sphere
489box b 10 10 10
490sphere s 5
491bfuse result b s
492checkshape result
493~~~~~
72b7576f 494
504a8968 495Make sure that file *parse.rules* in the grid or group directory contains a regular expression to catch possible messages indicating the failure of the test.
496
497For instance, for catching errors reported by *checkshape* command relevant grids define a rule to recognize its report by the word *Faulty*:
498
499~~~~~
500FAILED /\bFaulty\b/ bad shape
501~~~~~
502
503For the messages generated in the script it is recommended to use the word 'Error' in the error message.
72b7576f 504
72b7576f 505Example:
506
504a8968 507~~~~~
508set expected_length 11
509if { [expr $actual_length - $expected_length] > 0.001 } {
510 puts "Error: The length of the edge should be $expected_length"
511}
512~~~~~
513
514At the end, the test script should output *TEST COMPLETED* string to mark a successful completion of the script. This is often done by the *end* script in the grid.
515
516When the test script requires a data file, use Tcl procedure *locate_data_file* to get a path to it, instead of putting the path explicitly. This will allow easy move of the data file from OCCT sources repository to the data files repository without the need to update the test script.
72b7576f 517
72b7576f 518Example:
519
504a8968 520~~~~~
521stepread [locate_data_file CAROSKI_COUPELLE.step] a *
522~~~~~
523
936f43da 524When the test needs to produce some snapshots or other artefacts, use Tcl variable *imagedir* as the location where such files should be put.
525Command *testgrid* sets this variable to the subdirectory of the results folder corresponding to the grid.
526Command *test* by default creates dedicated temporary directory in the system temporary folder (normally the one specified by environment variable *TempDir*, *TEMP*, or *TMP*) for each execution, and sets *imagedir* to that location.
527However if variable *imagedir* is defined on top level of Tcl interpretor, command *test* will use it instead of creating a new directory.
528
529Use Tcl variable *casename* to prefix all files produced by the test.
530This variable is set to the name of the test case.
531For the image file (snapshot) to be recognized by the test system (for inclusion in HTML log and differences), its name should start with name of the test case (use variable *casename*), optionally followed by underscore or dash and arbitrary suffix.
532The image format (defined by extension) should be *png*.
72b7576f 533
72b7576f 534Example:
504a8968 535~~~~~
936f43da 536xwd $imagedir/${casename}.png
504a8968 537vdisplay result; vfit
936f43da 538vdump $imagedir/${casename}-axo.png
504a8968 539vfront; vfit
936f43da 540vdump $imagedir/${casename}-front.png
504a8968 541~~~~~
72b7576f 542
504a8968 543would produce:
544~~~~~
545A1.png
546A1-axo.png
547A1-front.png
548~~~~~
72b7576f 549
504a8968 550Note that OCCT must be built with FreeImage support to be able to produce usable images.
72b7576f 551
936f43da 552Other Tcl variables defined during the test execution are:
553- *groupname*: name of the test group
554- *gridname*: name of the test grid
555- *dirname*: path to the root directory of the current set of test scripts
556
504a8968 557In order to ensure that the test works as expected in different environments, observe the following additional rules:
558* Avoid using external commands such as *grep, rm,* etc., as these commands can be absent on another system (e.g. on Windows); use facilities provided by Tcl instead.
559* Do not put call to *locate_data_file* in catch statement – this can prevent correct interpretation of the missing data file by the test system.
72b7576f 560
504a8968 561@subsection testmanual_3_5 Interpretation of test results
72b7576f 562
504a8968 563The result of the test is evaluated by checking its output against patterns defined in the files *parse.rules* of the grid and group.
72b7576f 564
504a8968 565The OCCT test system recognizes five statuses of the test execution:
566* SKIPPED: reported if a line matching SKIPPED pattern is found (prior to any FAILED pattern). This indicates that the test cannot be run in the current environment; the most typical case is the absence of the required data file.
567* FAILED: reported if a line matching pattern with status FAILED is found (unless it is masked by the preceding IGNORE pattern or a TODO statement), or if message TEST COMPLETED is not found at the end. This indicates that the test has produced a bad or unexpected result, and usually means a regression.
568* BAD: reported if the test script output contains one or several TODO statements and the corresponding number of matching lines in the log. This indicates a known problem . The lines matching TODO statements are not checked against other patterns and thus will not cause a FAILED status.
569* IMPROVEMENT: reported if the test script output contains a TODO statement for which no corresponding line is found. This is a possible indication of improvement (a known problem has disappeared).
570* OK: reported if none of the above statuses have been assigned. This means that the test has passed without problems.
72b7576f 571
504a8968 572Other statuses can be specified in *parse.rules* files, these will be classified as FAILED.
72b7576f 573
504a8968 574For integration of the change to OCCT repository, all tests should return either OK or BAD status.
575The new test created for an unsolved problem should return BAD. The new test created for a fixed problem should return FAILED without the fix, and OK with the fix.
72b7576f 576
504a8968 577@subsection testmanual_3_6 Marking BAD cases
72b7576f 578
504a8968 579If the test produces an invalid result at a certain moment then corresponding bug should be created in the OCCT issue tracker located at http://tracker.dev.opencascade.org, and the problem should be marked as TODO in the test script.
72b7576f 580
504a8968 581The following statement should be added to such a test script:
582~~~~~
583puts "TODO BugNumber ListOfPlatforms: RegularExpression"
584~~~~~
585
586Here:
587* *BugNumber* is the bug ID in the tracker. For example: #12345.
588* *ListOfPlatforms* is a list of platforms at which the bug is reproduced (e.g. Mandriva2008, Windows or All). Note that the platform name is custom for the OCCT test system; it corresponds to the value of environment variable *os_type* defined in DRAW.
72b7576f 589
590Example:
504a8968 591~~~~~
592Draw[2]> puts $env(os_type)
593windows
594~~~~~
72b7576f 595
504a8968 596* RegularExpression is a regular expression which should be matched against the line indicating the problem in the script output.
72b7576f 597
72b7576f 598Example:
504a8968 599~~~~~
600puts "TODO #22622 Mandriva2008: Abort .* an exception was raised"
601~~~~~
72b7576f 602
504a8968 603The parser checks the test output and if an output line matches the *RegularExpression* then it will be assigned a BAD status instead of FAILED.
72b7576f 604
504a8968 605A separate TODO line must be added for each output line matching an error expression to mark the test as BAD. If not all TODO messages are found in the test log, the test will be considered as possible improvement.
606
607To mark the test as BAD for an incomplete case (when the final *TEST COMPLETE* message is missing) the expression *TEST INCOMPLETE* should be used instead of the regular expression.
72b7576f 608
609Example:
610
504a8968 611~~~~~
612puts "TODO OCC22817 All: exception.+There are no suitable edges"
613puts "TODO OCC22817 All: \\*\\* Exception \\*\\*"
614puts "TODO OCC22817 All: TEST INCOMPLETE"
615~~~~~
72b7576f 616
504a8968 617
618
619@section testmanual_4 Advanced Use
72b7576f 620
621@subsection testmanual_4_1 Running Tests on Older Versions of OCCT
622
504a8968 623Sometimes it might be necessary to run tests on previous versions of OCCT (<= 6.5.4) that do not include this test system. This can be done by adding DRAW configuration file *DrawAppliInit* in the directory which is current by the moment of DRAW start-up, to load test commands and to define necessary environment.
72b7576f 624
504a8968 625Note: in OCCT 6.5.3, file *DrawAppliInit* already exists in <i>$CASROOT/src/DrawResources</i>, new commands should be added to this file instead of a new one in the current directory.
626
627For example, let us assume that *d:/occt* contains an up-to-date version of OCCT sources with tests, and the test data archive is unpacked to *d:/test-data*):
628
629~~~~~
630set env(CASROOT) d:/occt
631set env(CSF_TestScriptsPath) $env(CASROOT)/tests
632source $env(CASROOT)/src/DrawResources/TestCommands.tcl
633set env(CSF_TestDataPath) $env(CASROOT)/data;d:/test-data
634return
635~~~~~
636
637Note that on older versions of OCCT the tests are run in compatibility mode and not all output of the test command can be captured; this can lead to absence of some error messages (can be reported as either a failure or an improvement).
638
639@subsection testmanual_4_2 Adding custom tests
640
641You can extend the test system by adding your own tests. For that it is necessary to add paths to the directory where these tests are located, and one or more additional data directories, to the environment variables *CSF_TestScriptsPath* and *CSF_TestDataPath*. The recommended way for doing this is using DRAW configuration file *DrawAppliInit* located in the directory which is current by the moment of DRAW start-up.
642
4ee1bdf4 643Use Tcl command <i>_path_separator</i> to insert a platform-dependent separator to the path list.
504a8968 644
645For example:
646~~~~~
647set env(CSF_TestScriptsPath) \
648 $env(TestScriptsPath)[_path_separator]d:/MyOCCTProject/tests
649set env(CSF_TestDataPath) \
650 d:/occt/test-data[_path_separator]d:/MyOCCTProject/data
651return ;# this is to avoid an echo of the last command above in cout
652~~~~~
653
654@subsection testmanual_4_3 Parallel execution of tests
655
656For better efficiency, on computers with multiple CPUs the tests can be run in parallel mode. This is default behavior for command *testgrid* : the tests are executed in parallel processes (their number is equal to the number of CPUs available on the system). In order to change this behavior, use option parallel followed by the number of processes to be used (1 or 0 to run sequentially).
72b7576f 657
87f42a3f 658Note that the parallel execution is only possible if Tcl extension package *Thread* is installed.
659If this package is not available, *testgrid* command will output a warning message.
72b7576f 660
504a8968 661@subsection testmanual_4_4 Checking non-regression of performance, memory, and visualization
72b7576f 662
504a8968 663Some test results are very dependent on the characteristics of the workstation, where they are performed, and thus cannot be checked by comparison with some predefined values. These results can be checked for non-regression (after a change in OCCT code) by comparing them with the results produced by the version without this change. The most typical case is comparing the result obtained in a branch created for integration of a fix (CR***) with the results obtained on the master branch before that change is made.
664
665OCCT test system provides a dedicated command *testdiff* for comparing CPU time of execution, memory usage, and images produced by the tests.
666
667~~~~~
668testdiff dir1 dir2 [groupname [gridname]] [options...]
669~~~~~
670Here *dir1* and *dir2* are directories containing logs of two test runs.
671
672Possible options are:
ba06f8bb 673* <i>-save \<filename\> </i> - saves the resulting log in a specified file (<i>$dir1/diff-$dir2.log</i> by default). HTML log is saved with the same name and extension .html;
504a8968 674* <i>-status {same|ok|all}</i> - allows filtering compared cases by their status:
675 * *same* - only cases with same status are compared (default);
676 * *ok* - only cases with OK status in both logs are compared;
677 * *all* - results are compared regardless of status;
ba06f8bb 678* <i>-verbose \<level\> </i> - defines the scope of output data:
504a8968 679 * 1 - outputs only differences;
680 * 2 - additionally outputs the list of logs and directories present in one of directories only;
681 * 3 - (by default) additionally outputs progress messages;
72b7576f 682
72b7576f 683Example:
504a8968 684
685~~~~~
686Draw[]> testdiff results-CR12345-2012-10-10T08:00 results-master-2012-10-09T21:20
687~~~~~
688
689@section testmanual_5 APPENDIX
690
691@subsection testmanual_5_1 Test groups
692
693@subsubsection testmanual_5_1_1 3rdparty
694
695This group allows testing the interaction of OCCT and 3rdparty products.
696
697DRAW module: VISUALIZATION.
698
699| Grid | Commands | Functionality |
700| :---- | :----- | :------- |
701| export | vexport | export of images to different formats |
702| fonts | vtrihedron, vcolorscale, vdrawtext | display of fonts |
703
704
705@subsubsection testmanual_5_1_2 blend
706
707This group allows testing blends (fillets) and related operations.
708
709DRAW module: MODELING.
710
711| Grid | Commands | Functionality |
712| :---- | :----- | :------- |
713| simple | blend | fillets on simple shapes |
714| complex | blend | fillets on complex shapes, non-trivial geometry |
715| tolblend_simple | tolblend, blend | |
716| buildevol | buildevol | |
717| tolblend_buildvol | tolblend, buildevol | use of additional command tolblend |
718| bfuseblend | bfuseblend | |
719| encoderegularity | encoderegularity | |
720
721@subsubsection testmanual_5_1_3 boolean
722
723This group allows testing Boolean operations.
724
725DRAW module: MODELING (packages *BOPTest* and *BRepTest*).
726
727Grids names are based on name of the command used, with suffixes:
728* <i>_2d</i> – for tests operating with 2d objects (wires, wires, 3d objects, etc.);
729* <i>_simple</i> – for tests operating on simple shapes (boxes, cylinders, toruses, etc.);
730* <i>_complex</i> – for tests dealing with complex shapes.
731
732| Grid | Commands | Functionality |
733| :---- | :----- | :------- |
734| bcommon_2d | bcommon | Common operation (old algorithm), 2d |
735| bcommon_complex | bcommon | Common operation (old algorithm), complex shapes |
736| bcommon_simple | bcommon | Common operation (old algorithm), simple shapes |
737| bcut_2d | bcut | Cut operation (old algorithm), 2d |
738| bcut_complex | bcut | Cut operation (old algorithm), complex shapes |
739| bcut_simple | bcut | Cut operation (old algorithm), simple shapes |
740| bcutblend | bcutblend | |
741| bfuse_2d | bfuse | Fuse operation (old algorithm), 2d |
742| bfuse_complex | bfuse | Fuse operation (old algorithm), complex shapes |
743| bfuse_simple | bfuse | Fuse operation (old algorithm), simple shapes |
744| bopcommon_2d | bopcommon | Common operation, 2d |
745| bopcommon_complex | bopcommon | Common operation, complex shapes |
746| bopcommon_simple | bopcommon | Common operation, simple shapes |
747| bopcut_2d | bopcut | Cut operation, 2d |
748| bopcut_complex | bopcut | Cut operation, complex shapes |
749| bopcut_simple | bopcut | Cut operation, simple shapes |
750| bopfuse_2d | bopfuse | Fuse operation, 2d |
751| bopfuse_complex | bopfuse | Fuse operation, complex shapes |
752| bopfuse_simple | bopfuse | Fuse operation, simple shapes |
753| bopsection | bopsection | Section |
754| boptuc_2d | boptuc | |
755| boptuc_complex | boptuc | |
756| boptuc_simple | boptuc | |
757| bsection | bsection | Section (old algorithm) |
758
759@subsubsection testmanual_5_1_4 bugs
760
761This group allows testing cases coming from Mantis issues.
762
763The grids are organized following OCCT module and category set for the issue in the Mantis tracker.
764See <a href="#testmanual_5_2">Mapping of OCCT functionality to grid names in group *bugs*</a> for details.
765
766@subsubsection testmanual_5_1_5 caf
767
768This group allows testing OCAF functionality.
769
770DRAW module: OCAFKERNEL.
771
772| Grid | Commands | Functionality |
773| :---- | :----- | :------- |
774| basic | | Basic attributes |
775| bugs | | Saving and restoring of document |
776| driver | | OCAF drivers |
777| named_shape | | *TNaming_NamedShape* attribute |
778| presentation | | *AISPresentation* attributes |
779| tree | | Tree construction attributes |
780| xlink | | XLink attributes |
781
782@subsubsection testmanual_5_1_6 chamfer
783
784This group allows testing chamfer operations.
785
786DRAW module: MODELING.
787
788The test grid name is constructed depending on the type of the tested chamfers. Additional suffix <i>_complex</i> is used for test cases involving complex geometry (e.g. intersections of edges forming a chamfer); suffix <i>_sequence</i> is used for grids where chamfers are computed sequentially.
789
790| Grid | Commands | Functionality |
791| :---- | :----- | :------- |
792| equal_dist | | Equal distances from edge |
793| equal_dist_complex | | Equal distances from edge, complex shapes |
794| equal_dist_sequence | | Equal distances from edge, sequential operations |
795| dist_dist | | Two distances from edge |
796| dist_dist_complex | | Two distances from edge, complex shapes |
797| dist_dist_sequence | | Two distances from edge, sequential operations |
798| dist_angle | | Distance from edge and given angle |
799| dist_angle_complex | | Distance from edge and given angle |
800| dist_angle_sequence | | Distance from edge and given angle |
801
802@subsubsection testmanual_5_1_7 demo
803
804This group allows demonstrating how testing cases are created, and testing DRAW commands and the test system as a whole.
805
806| Grid | Commands | Functionality |
807| :---- | :----- | :------- |
808| draw | getsource, restore | Basic DRAW commands |
809| testsystem | | Testing system |
810| samples | | OCCT samples |
811
812
813@subsubsection testmanual_5_1_8 draft
814
815This group allows testing draft operations.
816
817DRAW module: MODELING.
818
819| Grid | Commands | Functionality |
820| :---- | :----- | :------- |
821| Angle | depouille | Drafts with angle (inclined walls) |
822
823
824@subsubsection testmanual_5_1_9 feat
825
826This group allows testing creation of features on a shape.
827
828DRAW module: MODELING (package *BRepTest*).
829
830| Grid | Commands | Functionality |
831| :---- | :----- | :------- |
832| featdprism | | |
833| featlf | | |
834| featprism | | |
835| featrevol | | |
836| featrf | | |
837
838@subsubsection testmanual_5_1_10 heal
839
840This group allows testing the functionality provided by *ShapeHealing* toolkit.
841
842DRAW module: XSDRAW
843
844| Grid | Commands | Functionality |
845| :---- | :----- | :------- |
846| fix_shape | fixshape | Shape healing |
847| fix_gaps | fixwgaps | Fixing gaps between edges on a wire |
848| same_parameter | sameparameter | Fixing non-sameparameter edges |
849| fix_face_size | DT_ApplySeq | Removal of small faces |
850| elementary_to_revolution | DT_ApplySeq | Conversion of elementary surfaces to revolution |
851| direct_faces | directfaces | Correction of axis of elementary surfaces |
852| drop_small_edges | fixsmall | Removal of small edges |
853| split_angle | DT_SplitAngle | Splitting periodic surfaces by angle |
854| split_angle_advanced | DT_SplitAngle | Splitting periodic surfaces by angle |
855| split_angle_standard | DT_SplitAngle | Splitting periodic surfaces by angle |
856| split_closed_faces | DT_ClosedSplit | Splitting of closed faces |
857| surface_to_bspline | DT_ToBspl | Conversion of surfaces to b-splines |
858| surface_to_bezier | DT_ShapeConvert | Conversion of surfaces to bezier |
859| split_continuity | DT_ShapeDivide | Split surfaces by continuity criterion |
860| split_continuity_advanced | DT_ShapeDivide | Split surfaces by continuity criterion |
861| split_continuity_standard | DT_ShapeDivide | Split surfaces by continuity criterion |
862| surface_to_revolution_advanced | DT_ShapeConvertRev | Convert elementary surfaces to revolutions, complex cases |
863| surface_to_revolution_standard | DT_ShapeConvertRev | Convert elementary surfaces to revolutions, simple cases |
864
865@subsubsection testmanual_5_1_11 mesh
866
4ee1bdf4 867This group allows testing shape tessellation (*BRepMesh*) and shading.
504a8968 868
869DRAW modules: MODELING (package *MeshTest*), VISUALIZATION (package *ViewerTest*)
870
871| Grid | Commands | Functionality |
872| :---- | :----- | :------- |
873| advanced_shading | vdisplay | Shading, complex shapes |
874| standard_shading | vdisplay | Shading, simple shapes |
875| advanced_mesh | mesh | Meshing of complex shapes |
876| standard_mesh | mesh | Meshing of simple shapes |
877| advanced_incmesh | incmesh | Meshing of complex shapes |
878| standard_incmesh | incmesh | Meshing of simple shapes |
879| advanced_incmesh_parallel | incmesh | Meshing of complex shapes, parallel mode |
880| standard_incmesh_parallel | incmesh | Meshing of simple shapes, parallel mode |
881
882@subsubsection testmanual_5_1_12 mkface
883
884This group allows testing creation of simple surfaces.
885
886DRAW module: MODELING (package *BRepTest*)
887
888| Grid | Commands | Functionality |
889| :---- | :----- | :------- |
890| after_trim | mkface | |
891| after_offset | mkface | |
892| after_extsurf_and_offset | mkface | |
893| after_extsurf_and_trim | mkface | |
894| after_revsurf_and_offset | mkface | |
895| mkplane | mkplane | |
896
897@subsubsection testmanual_5_1_13 nproject
898
899This group allows testing normal projection of edges and wires onto a face.
900
901DRAW module: MODELING (package *BRepTest*)
902
903| Grid | Commands | Functionality |
904| :---- | :----- | :------- |
905| Base | nproject | |
906
907@subsubsection testmanual_5_1_14 offset
908
909This group allows testing offset functionality for curves and surfaces.
910
911DRAW module: MODELING (package *BRepTest*)
912
913| Grid | Commands | Functionality |
914| :---- | :----- | :------- |
915| compshape | offsetcompshape | Offset of shapes with removal of some faces |
916| faces_type_a | offsetparameter, offsetload, offsetperform | Offset on a subset of faces with a fillet |
917| faces_type_i | offsetparameter, offsetload, offsetperform | Offset on a subset of faces with a sharp edge |
918| shape_type_a | offsetparameter, offsetload, offsetperform | Offset on a whole shape with a fillet |
919| shape_type_i | offsetparameter, offsetload, offsetperform | Offset on a whole shape with a fillet |
920| shape | offsetshape | |
921| wire_closed_outside_0_005, wire_closed_outside_0_025, wire_closed_outside_0_075, wire_closed_inside_0_005, wire_closed_inside_0_025, wire_closed_inside_0_075, wire_unclosed_outside_0_005, wire_unclosed_outside_0_025, wire_unclosed_outside_0_075 | mkoffset | 2d offset of closed and unclosed planar wires with different offset step and directions of offset ( inside / outside ) |
922
923@subsubsection testmanual_5_1_15 pipe
924
925This group allows testing construction of pipes (sweeping of a contour along profile).
926
927DRAW module: MODELING (package *BRepTest*)
928
929| Grid | Commands | Functionality |
930| :---- | :----- | :------- |
931| Standard | pipe | |
932
933@subsubsection testmanual_5_1_16 prism
934
935This group allows testing construction of prisms.
936
937DRAW module: MODELING (package *BRepTest*)
938
939| Grid | Commands | Functionality |
940| :---- | :----- | :------- |
941| seminf | prism | |
942
943@subsubsection testmanual_5_1_17 sewing
944
945This group allows testing sewing of faces by connecting edges.
946
947DRAW module: MODELING (package *BRepTest*)
948
949| Grid | Commands | Functionality |
950| :---- | :----- | :------- |
951| tol_0_01 | sewing | Sewing faces with tolerance 0.01 |
952| tol_1 | sewing | Sewing faces with tolerance 1 |
953| tol_100 | sewing | Sewing faces with tolerance 100 |
954
955@subsubsection testmanual_5_1_18 thrusection
956
957This group allows testing construction of shell or a solid passing through a set of sections in a given sequence (loft).
958
959| Grid | Commands | Functionality |
960| :---- | :----- | :------- |
961| solids | thrusection | Lofting with resulting solid |
962| not_solids | thrusection | Lofting with resulting shell or face |
963
964@subsubsection testmanual_5_1_19 xcaf
965
966This group allows testing extended data exchange packages.
967
968| Grid | Commands | Functionality |
969| :---- | :----- | :------- |
970| dxc, dxc_add_ACL, dxc_add_CL, igs_to_dxc, igs_add_ACL, brep_to_igs_add_CL, stp_to_dxc, stp_add_ACL, brep_to_stp_add_CL, brep_to_dxc, add_ACL_brep, brep_add_CL | | Subgroups are divided by format of source file, by format of result file and by type of document modification. For example, *brep_to_igs* means that the source shape in brep format was added to the document, which was saved into igs format after that. The postfix *add_CL* means that colors and layers were initialized in the document before saving and the postfix *add_ACL* corresponds to the creation of assembly and initialization of colors and layers in a document before saving. |
971
972
973@subsection testmanual_5_2 Mapping of OCCT functionality to grid names in group *bugs*
974
975| OCCT Module / Mantis category | Toolkits | Test grid in group bugs |
976| :---------- | :--------- | :---------- |
977| Application Framework | PTKernel, TKPShape, TKCDF, TKLCAF, TKCAF, TKBinL, TKXmlL, TKShapeSchema, TKPLCAF, TKBin, TKXml, TKPCAF, FWOSPlugin, TKStdLSchema, TKStdSchema, TKTObj, TKBinTObj, TKXmlTObj | caf |
978| Draw | TKDraw, TKTopTest, TKViewerTest, TKXSDRAW, TKDCAF, TKXDEDRAW, TKTObjDRAW, TKQADraw, DRAWEXE, Problems of testing system | draw |
979| Shape Healing | TKShHealing | heal |
980| Mesh | TKMesh, TKXMesh | mesh |
981| Data Exchange | TKIGES | iges |
982| Data Exchange | TKSTEPBase, TKSTEPAttr, TKSTEP209, TKSTEP | step |
983| Data Exchange | TKSTL, TKVRML | stlvrml |
984| Data Exchange | TKXSBase, TKXCAF, TKXCAFSchema, TKXDEIGES, TKXDESTEP, TKXmlXCAF, TKBinXCAF | xde |
6268cc68 985| Foundation Classes | TKernel, TKMath | fclasses |
504a8968 986| Modeling_algorithms | TKGeomAlgo, TKTopAlgo, TKPrim, TKBO, TKBool, TKHLR, TKFillet, TKOffset, TKFeat, TKXMesh | modalg |
987| Modeling Data | TKG2d, TKG3d, TKGeomBase, TKBRep | moddata |
988| Visualization | TKService, TKV2d, TKV3d, TKOpenGl, TKMeshVS, TKNIS, TKVoxel | vis |
989
990
5ae01c85 991@subsection testmanual_5_3 Recommended approaches to checking test results
504a8968 992
993@subsubsection testmanual_5_3_1 Shape validity
994
995Run command *checkshape* on the result (or intermediate) shape and make sure that *parse.rules* of the test grid or group reports bad shapes (usually recognized by word "Faulty") as error.
996
997Example
998~~~~~
999checkshape result
1000~~~~~
1001
5ae01c85 1002To check the number of faults in the shape command *checkfaults* can be used.
1003
1004Use: checkfaults shape source_shape [ref_value=0]
1005
1006The default syntax of *checkfaults* command:
1007~~~~~
1008checkfaults results a_1
1009~~~~~
1010
1011The command will check the number of faults in the source shape (*a_1*) and compare it
1012with number of faults in the resulting shape (*result*). If shape *result* contains
1013more faults, you will get an error:
1014~~~~~
1015checkfaults results a_1
1016Error : Number of faults is 5
1017~~~~~
1018It is possible to set the reference value for comparison (reference value is 4):
1019
1020~~~~~
1021checkfaults results a_1 4
1022~~~~~
1023
1024If number of faults in the resulting shape is unstable, reference value should be set to "-1".
1025As a result command *checkfaults* will return the following error:
1026
1027~~~~~
1028checkfaults results a_1 -1
1029Error : Number of faults is UNSTABLE
1030~~~~~
1031
504a8968 1032@subsubsection testmanual_5_3_2 Shape tolerance
1033The maximal tolerance of sub-shapes of each kind of the resulting shape can be extracted from output of tolerance command as follows:
1034
1035~~~~~
1036set tolerance [tolerance result]
1037regexp { *FACE +: +MAX=([-0-9.+eE]+)} $tolerance dummy max_face
1038regexp { *EDGE +: +MAX=([-0-9.+eE]+)} $tolerance dummy max_edgee
1039regexp { *VERTEX +: +MAX=([-0-9.+eE]+)} $tolerance dummy max_vertex
1040~~~~~
1041
5ae01c85 1042It is possible to use command *checkmaxtol* to check maximal tolerance of shape and compare it with reference value.
1043
1044Use: checkmaxtol shape ref_value [source_shapes={}] [options...]
1045
1046Allowed options are:
1047 * -min_tol: minimum tolerance for comparison
1048 * -multi_tol: tolerance multiplier
1049
1050Argument "source_shapes" is a list of shapes to compare with.
1051It can be empty to skip comparison of tolerance with these shapes.
1052
1053The default syntax of *checkmaxtol* command for comparison with the reference value:
1054~~~~~
1055checkmaxtol result 0.00001
1056~~~~~
1057
1058There is an opportunity to compare max tolerance of resulting shape with max tolerance of source shape.
1059In the following example command *checkmaxtol* gets max tolerance among objects *a_1* and *a_2*.
1060Then it chooses the maximum value between founded tolerance and value -min_tol (0.000001)
1061and multiply it on the coefficient -multi_tol (i.e. 2):
1062
1063~~~~~
1064checkmaxtol result 0.00001 {a_1 a_2} -min_tol 0.000001 -multi_tol 2
1065~~~~~
1066
1067If the value of maximum tolerance more than founded tolerance for comparison, the command will return an error.
1068
504a8968 1069@subsubsection testmanual_5_3_3 Shape volume, area, or length
1070
1071Use command *vprops, sprops,* or *lprops* to correspondingly measure volume, area, or length of the shape produced by the test. The value can be extracted from the result of the command by *regexp*.
1072
1073Example:
1074~~~~~
1075# check area of shape result with 1% tolerance
1076regexp {Mass +: +([-0-9.+eE]+)} [sprops result] dummy area
1077if { abs($area - $expected) > 0.1 + 0.01 * abs ($area) } {
1078 puts "Error: The area of result shape is $area, while expected $expected"
1079}
1080~~~~~
1081
1082@subsubsection testmanual_5_3_4 Memory leaks
1083
1084The test system measures the amount of memory used by each test case, and considerable deviations (as well as overall difference) comparing with reference results will be reported by *testdiff* command.
1085
1086The typical approach to checking memory leak on a particular operation is to run this operation in cycle measuring memory consumption at each step and comparing it with some threshold value. Note that file begin in group bugs defines command *checktrend* that can be used to analyze a sequence of memory measurements to get statistically based evaluation of the leak presence.
1087
1088Example:
1089~~~~~
1090set listmem {}
1091for {set i 1} {$i < 100} {incr i} {
1092 # run suspect operation
1093
1094 # check memory usage (with tolerance equal to half page size)
1095 lappend listmem [expr [meminfo w] / 1024]
1096 if { [checktrend $listmem 0 256 "Memory leak detected"] } {
1097 puts "No memory leak, $i iterations"
1098 break
1099 }
1100}
1101~~~~~
1102
1103@subsubsection testmanual_5_3_5 Visualization
1104
936f43da 1105Take a snapshot of the viewer, give it the name of the test case, and save in the directory indicated by Tcl variable *imagedir*.
504a8968 1106
1107~~~~~
1108vinit
1109vclear
1110vdisplay result
1111vsetdispmode 1
1112vfit
1113vzfit
1114vdump $imagedir/${casename}_shading.png
1115~~~~~
1116
1117This image will be included in the HTML log produced by *testgrid* command and will be checked for non-regression through comparison of images by command *testdiff*.
5ae01c85 1118
1119@subsubsection testmanual_5_3_6 Number of free edges
1120
1121To check the number of free edges run the command *checkfreebounds*.
1122
1123It compares number of free edges with reference value.
1124
1125Use: checkfreebounds shape ref_value [options...]
1126
1127Allowed options are:
1128 * -tol N: used tolerance (default -0.01)
1129 * -type N: used type, possible values are "closed" and "opened" (default "closed")
1130
1131~~~~~
1132checkfreebounds result 13
1133~~~~~
1134
1135Option -tol N is used to set tolerance for command *freebounds*, which is used within command *checkfreebounds*.
1136
1137Option -type N is used to select the type of counted free edges - closed or opened.
1138
1139If the number of free edges in the resulting shape is unstable, reference value should be set to "-1".
1140As a result command *checkfreebounds* will return the following error:
1141
1142~~~~~
1143checkfreebounds result -1
1144Error : Number of free edges is UNSTABLE
1145~~~~~
1146
1147@subsubsection testmanual_5_3_7 Compare numbers
1148
1149Procedure to check equality of two reals with some tolerance (relative and absolute)
1150
1151Use: checkreal name value expected tol_abs tol_rel
1152
1153~~~~~
1154checkreal "Some important value" $value 5 0.0001 0.01
1155~~~~~
1156
1157@subsubsection testmanual_5_3_8 Check number of sub-shapes
1158
1159Compare number of sub-shapes in "shape" with given reference data
1160
1161Use: checknbshapes shape [options...]
1162Allowed options are:
1163 * -vertex N
1164 * -edge N
1165 * -wire N
1166 * -face N
1167 * -shell N
1168 * -solid N
1169 * -compsolid N
1170 * -compound N
1171 * -shape N
1172 * -t: compare the number of sub-shapes in "shape" counting
1173 the same sub-shapes with different location as different sub-shapes.
1174 * -m msg: print "msg" in case of error
1175
1176~~~~~
1177checknbshapes result -vertex 8 -edge 4
1178~~~~~
1179
1180@subsubsection testmanual_5_3_9 Check pixel color
1181
1182To check pixel color command *checkcolor* can be used.
1183
1184Use: checkcolor x y red green blue
1185
1186 x y - pixel coordinates
1187
1188 red green blue - expected pixel color (values from 0 to 1)
1189
1190This procedure checks color with tolerance (5x5 area)
1191
1192Next example will compare color of point with coordinates x=100 y=100 with RGB color R=1 G=0 B=0.
1193If colors are not equal, procedure will check the nearest ones points (5x5 area)
1194~~~~~
1195checkcolor 100 100 1 0 0
1196~~~~~