T4S4  18.2 C7549 A21431
Teamcenter Gateway for SAP S/4HANA API Reference
T4X::TNT Namespace Reference

Commands to work with the Test and Teach framework (TNT). More...

Namespaces

 Assert
 Commands to compare expected with actual results. They must only be called from within verify procedures. Call them without any namespace identifier.
 
 DefinitionLanguage
 Commands to create and configure demo cases and groups.
 
 DemoCase
 Commands to retrieve information about the demo case currently being executed. They must only be called from within demo case namespaces.
 
 DemoSuite
 Commands to retrieve information about the demo suite currently being executed. They must only be called from within demo case namespaces.
 

Functions

 canExecuteDemoSuite namespace ?optionsVar?
 Test whether all preconditions defined in a demo suite are met. More...
 
 executeDemoSuite namespace testResultsVar ?optionsVar?
 Execute demo suite as a test. More...
 
 executeTests args
 Execute demo suite as a test (deprecated). More...
 
 formatTestReport testResultsVar
 Format the test results into a list of lines. More...
 
 getNetResult testResultsIn
 
 getNonGood testResultsIn
 Returns the list of demo cases that did not complete with GOOD. More...
 
 getStatus testResultsIn demoCase
 
 htmlCloseFile channel ?optionsVar?
 Close an HTML file opened to receive the documentation to be generated through the htmlWriteLessons command. More...
 
 htmlOpenFile htmlOutputFileName ?optionsVar?
 Open an HTML file to receive the documentation to be generated through the htmlWriteLessons command. More...
 
 htmlWriteLessons outChannel namespace ?optionsVar?
 Derive documentation from a demo suite and write it to an HTML file. More...
 
 logTestReport testResultsVar ?logChannel?
 Output test results using the tpwrite command. More...
 
 putCode namespace ?optionsVar?
 Generate code from the demo suite and output the code using the puts command. More...
 
 putLessons namespace ?optionsVar?
 Output the title, lesson and code parts of demo suite using the puts command. More...
 
 putOverview namespace ?optionsVar?
 Output the title, and code parts of demo suite using the puts command. More...
 
 putTestReport testResultsVar
 Output test results using the puts command. More...
 
 setProperties fullName args
 Assign properties to a demo case and set their values. More...
 
 splitCode text width
 
 succeeded testResultsIn
 
 writeLessons writer namespace ?optionsVar?
 Derive documentation from a demo suite and write it with the given writer. More...
 

Detailed Description

Commands to work with the Test and Teach framework (TNT).

Demo Suites and Demo Cases

Formulate demo suites containing demo cases, similar to test suites and test cases, and feed them into the TNT using the commands in this namespace. The result will be the execution of the tests with a test report you can output or documentation in several formats.

The demo suites are specified as Tcl namespaces including subordinate namespaces for the demo cases. The demo case namespaces may include the following attributes:

  • title variable - A brief description of what the commands used in the test do. Each line may start with a hash symbol ("#"). This way Tcl-Editors can format the descriptive text as they do with Tcl comments.
  • description variable - Text that describes the demo case. Formatted the same way as the title field.
  • lesson variable - Text that explains the commands used in the demo case in detail. Each line may start with a hash symbol ("#") like in the title field. In addition markup symbols contained in the text are interpreted it the output format is HTML. See markup.
  • note variable - Short note that will be output if the execution of a demo case succeeded.
  • testBefore variable - list of demo cases which must have been executed prior to running this demo case. See also depends variable below.
  • knowBefore variable - list of demo cases the lessons of which should have been read before reading the lesson of this test. See also depends variable below.
  • depends variable - list of tests which you would enter into testBefore as well as knowBefore can be put here.
  • precondition procedure - The code defined in this procedure is executed prior to executing the code to be tested. It must return a true boolean if the the actual code can be executed or false if it cannot. See Preconditions below. The code in a precondition procedure must not depend on results from code to be executed as a test.

    Example:

    1 namespace eval GeneralWsdlImportTest {
    2  [...]
    3  proc precondition {} {
    5  file isdirectory $inputDir
    6  }
    7  [...]
    8 }
  • code procedure - The code to execute for the demo case. It may use variables set in dependent demo cases and set variables for other demo cases and for the verify section.
  • examples procedure - Additional code not executed for the test but shown to give more examples of how the commands under test may be used.
  • bad procedure - This code is executed in the course of a test like code. It is however expected to throw an error. This is used to verify that a particular error condition gets recognized.
  • verify procedure - The code to verify the results raised in the code section. It may contain calls to the Assert::assertEquals, Assert::assertTrue, Assert::assertFalse, etc. procedures to verify the correctness of values produced by the test objects.
  • lazy variable - If set to true this demo case will not be executed unless
    • it is a dependency of another demo case or
    • it is found by a filter
  • hidden variable - If set to true and the showHidden option is not set to true the output and test result of the demo case will not be shown. This is implicitly set to true for implicit life-cycle demo cases.
  • immune variable - If set to true the demo case will be executed even if there are failed dependencies. This is implicitly set to true for TearDown life-cycle demo cases.
  • type variable - You can use this to explicitly declare the purpose of a Tcl namespace. It can be SetUp, TearDown, DemoCase or Group. Normally there is no need to set this variable as the type is determined from the name or content of the namespace. Only if you want to name a SetUp or TearDown demo case other than _SetUp_ or _TearDown_ resp. you need to set the type.

Properties

Demo cases can have properties. A property has a name and a value. The value can be retrieved using the DemoCase::getProperty command from within a demo case and the setProperties command from outside the demo case. You can also set properties using the commands from the DefinitionLanguage namespace.

Attributes defined by writing a procedure such as code code can call the DemoCase::getProperty command or encounter the names of the properties in their argument lists.

This can be used to parameterize demo cases.

The following example creates a demo suite with two parameterized demo cases. They only differ in the protocol HTTP or HTTPS to be used to cal a REST service:

1 namespace eval JsonRestTests {
2  foreach protocol in {http https} {
3  namespace eval [DemoCase CallTest${protocol} protocol $protocol] {
4  proc code {protocol} {
5  ::MyJsonRestClient::call
6 ${protocol}://jsonplaceholder.typicode.com/posts/13
7  }
8  }
9  }
10 }

Groups

Demo cases can be organized in groups. Groups are represented as namespaces like demo cases or demo suites. A namespace that has any of the elements that are typical for a demo case like a code proc, or a depends variable is considered a demo case. Otherwise it is considered a group. This applies to the demo suite as well.

Life-cycle Demo Cases

You can create SetUp and TearDown demo cases to execute operations that create edge conditions for regular demo cases or do clean up tasks after regular demo cases have finished.

SetUp and TearDown demo cases are called life-cycle demo cases.

Life-cycle demo cases are associated with Groups. Every group, including the demo suite, has at least one SetUp and one TearDown demo case. They can be formulated as Tcl namespaces named _SetUp_ or _TearDown_ resp. or as namespaces whose type variable is set to SetUp or TearDown resp. If a group is lacking such namespaces implicit life-cycle demo cases will automatically be created behind the scenes. They will have the hidden attribute set to true.

Dependency relations of SetUp Demo Cases

All regular demo cases of a group (DC1 and DC2 in the picture below) depend on the SetUp demo cases (SU below) of the group as shown below:

┌─ DC1
SU ←─┤
└─ DC2

If a group (G1 below in dotted rectangle) has a parent group its SetUp demo cases depend on the SetUp demo cases of the parent group:

┌─ DC1
SU ←─┬─┤
│ └─ DC2
. . . .│. . . . . . . . . . . . .
. │ .
. │ ┌─ G1.DC1 .
. G1 └─ G1.SU ←─┤ .
. └─ G1.DC2 .
. .
. . . . . . . . . . . . . . . . .

Dependency relations of TearDown Demo Cases

TearDown demo cases (TD in the picture below) depend on all demo cases (DC1 and DC2 below) of the same group:

┌─ DC1 ←─┐
SU ←─┬─┤ ├─┬─ TD
│ └─ DC2 ←─┘ │
└────────────┘

If a group (G1 below in dotted rectangle) has a parent group its TearDown demo cases act as dependencies for the parent group:

┌─ DC1 ←─┐
SU ←─┬────────────┬─┤ ├─┬─────────────┬─ TD
│ │ └─ DC2 ←─┘ │ │
│ └────────────┘ │
│ │
. . . .│. . . . . . . . . . . . . . . . . . . .│. .
. │ │ .
. │ ┌─ G1.DC1 ←─┐ │ .
. G1 └─ G1.SU ←──┬─┤ ├─┬─ G1.TD ←─┘ .
. │ └─ G1.DC2 ←─┘ │ .
. └───────────────┘ .
. .
. . . . . . . . . . . . . . . . . . . . . . . . . .

Dependency relations between groups

A demo case can depend on a demo case of another group. The name given in the depends variable is searched in the same group first then in the parent group and so on. The name can be qualified with the name of the group to address a demo case of a child or sibling group.

Dependency relations between life-cycle demo cases of different groups

There is no implicit guarantee that all demo cases of one group are executed before all demo cases of another group. In order to achieve this create a dependency to the TearDown demo case of the group to be executed first from the SetUp demo case of the group to be executed afterwards:

. . . . . . . . . . . . . . . . . . . . . . . . . .
. .
. ┌─ G1.DC1 ←─┐ .
. G1 G1.SU ←──┬─┤ ├─┬─ G1.TD ←─┐ .
. │ └─ G1.DC2 ←─┘ │ │ .
. └───────────────┘ │ .
. │ .
. . . . . . . . . . . . . . . . . . . . . . . .│. .
dependency to be added │
┌───────────────────────────────────────┘
. . . .│. . . . . . . . . . . . . . . . . . . . . .
. │ .
. │ ┌─ G2.DC1 ←─┐ .
. G2 └─ G2.SU ←──┬─┤ ├─┬─ G2.TD .
. │ └─ G2.DC2 ←─┘ │ .
. └───────────────┘ .
. .
. . . . . . . . . . . . . . . . . . . . . . . . . .

Code example:

1 namespace eval DemoSuite {
2  namespace eval G1 {
3  [...]
4  }
5 
6  namespace eval G2 {
7  namespace eval _SetUp_ {
8  set depends { G1::_TearDown_ }
9  }
10  [...]
11  }
12 }

Inheritance

Groups including demo suites can have their inherits variable set. Such variables contain lists of a specific format: On odd positions there are namespace names of groups to be inherited. On even positions they have lists of glob patterns with ? and * as wildcards (see documentation of the string match command). If the inherits variable contains an odd number of element a pattern list with the * wildcard as the only pattern is implicitly added. The pattern lists are used to select subsets of demo cases from the inherited groups.

Note that the lists don't have to be well-formed Tcl lists as produced by the list command. This a allows for a more terse syntax than with nested list invocations.

Demo cases inherited from groups can be overridden by demo cases in the inheriting group. They need to have the same namespace name and can redefine any attribute of the inherited demo cases.

The following examples shows how the demo suites for testing a fictional JDBC library might look like. The examples are minimized to focus on demonstrating the effects of inheritance. A real test scenario would of course contain more assertions, code and documentation.

Code example:

1 namespace eval ConnectToJDBCSuite {
2  namespace eval SpecifyDriverClassName {
3  proc verify {} {
4  assertTrue [info exists jdbcDriver]
5  }
6  }
7  namespace eval SpecifyConnectUrlDemo {
8  proc verify {} {
9  assertTrue [info exists connectUrl]
10  }
11  }
12  namespace eval ConnectDemo {
13  set depends { SpecifyDriverClassNameDemo SpecifyConnectUrlDemo }
14  proc code {} {
15  set connection [jdbc::connect $jdbcDriver $connectUrl]
16  }
17  }
18  namespace eval PrintJdbcVersionDemo {
19  set depends { ConnectDemo }
20  proc code {} {
21  set databaseInfo [jdbc::getDatabaseInfo $connection]
22  }
23  }
24  namespace eval DisconnectDemo {
25  set type TearDown
26  proc code {} {
27  jdbc::close $connection
28  }
29  }
30 }
31 
32 namespace eval ConnectToOracleSuite {
33  inherits { ConnectToJDBCSuite }
34 
35  namespace eval SpecifyDriverClassNameDemo {
36  proc code {} {
37  set jdbcDriver "oracle.jdbc.driver.OracleDriver"
38  }
39  }
40  namespace eval SpecifyConnectUrlDemo {
41  proc code {} {
42  set connectUrl "jdbc:oracle:thin:@localhost:1521:testdb"
43  }
44  }
45 }

In the above example the ConnectToJDBCSuite demo suite will not be executed but just used as a blue print to be inherited from. If it were executed the assertTrue [info exists connectUrl] and assertTrue [info exists jdbcDriver] assertions would fail. Instead the ConnectToOracleSuite can be executed as it provides the missing pieces of code to create the required variables.

Setting inherits to { ConnectToJDBCSuite * } or { ConnectToJDBCSuite {*} } is equivalent to { ConnectToJDBCSuite * }.

Note that the type of the DisconnectDemo demo case is explicitly set to TearDown to ensure the connection is closed after executing the other demo cases.

Lets extend the example so that you can test SQL data definition and manipulation language statements.

Code example:

1 namespace eval JdbcWithOracleSuite {
2  set inherits { ConnectToOracleSuite }
3  namespace eval CreateTableDemo {
4  set depends { ConnectDemo }
5  proc code {} {
6  jdbc::executeQuery $connection "CREATE TABLE Employees ..."
7  }
8  }
9  namespace eval InsertIntoDemo {
10  set depends { CreateTableDemo }
11  proc code {} {
12  jdbc::executeQuery $connection "INSERT INTO Employees ..."
13  }
14  }
15  namespace eval SelectDemo {
16  set depends { InsertIntoDemo }
17  proc code {} {
18  jdbc::executeQuery $connection "SELECT * FROM Employees ..."
19  }
20  }
21 }

In the above example the JdbcWithOracleSuite demo suite inherits from the ConnectToOracleSuite so the programming code used to establish and close the data base connection does not have to be repeated.

Lets assume now you want to do the same tests with a MySql data base. You create

1 namespace eval ConnectToMySqlSuite {
2  inherits { ConnectToJDBCSuite }
3 
4  namespace eval SpecifyDriverClassNameDemo {
5  proc code {} {
6  set jdbcDriver "com.mysql.jdbc.Driver"
7  }
8  }
9  namespace eval SpecifyConnectUrlDemo {
10  proc code {} {
11  set connectUrl "jdbc:mysql://local:1621/testdb"
12  }
13  }
14 }
15 namespace eval JdbcWithMySqlSuite {
16  set inherits { ConnectToMySqlSuite }
17  namespace eval CreateTableDemo {
18  set depends { ConnectDemo }
19  proc code {} {
20  jdbc::executeQuery $connection "CREATE TABLE Employees ..."
21  }
22  }
23  namespace eval InsertIntoDemo {
24  set depends { CreateTableDemo }
25  proc code {} {
26  jdbc::executeQuery $connection "INSERT INTO Employees ..."
27  }
28  }
29  namespace eval SelectDemo {
30  set depends { InsertIntoDemo }
31  proc code {} {
32  jdbc::executeQuery $connection "SELECT * FROM Employees ..."
33  }
34  }
35 }

The tests for the SQL data definition and manipulation language statements are the same for Oracle and MySql so you will want to define them independently of the database system as shown below:

1 namespace eval DdlAndDmlStatementsGroup {
2  namespace eval CreateTableDemo {
3  set depends { ConnectDemo }
4  proc code {} {
5  jdbc::executeQuery $connection "CREATE TABLE Employees ..."
6  }
7  }
8  namespace eval InsertIntoDemo {
9  set depends { CreateTableDemo }
10  proc code {} {
11  jdbc::executeQuery $connection "INSERT INTO Employees ..."
12  }
13  }
14  namespace eval SelectDemo {
15  set depends { InsertIntoDemo }
16  proc code {} {
17  jdbc::executeQuery $connection "SELECT * FROM Employees ..."
18  }
19  }
20 }

The JdbcWithOracleSuite and JdbcWithMySqlSuite demo suites would then become

1 namespace eval JdbcWithOracleSuite {
2  set inherits { ConnectToOracleSuite * DdlAndDmlStatementsGroup *}
3 }
4 namespace eval JdbcWithMySqlSuite {
5  set inherits { ConnectToMySqlSuite * DdlAndDmlStatementsGroup *}
6 }

Now you want to test your JDBCConnector product which makes use of the JDBC library and the creation of the driver class names and the connect URLs are the only pieces of code you can reuse from the demo suites so far. So write the code such that it only inherits the respective demo cases. The example assumes you want to test with the MySql database and all the tests are defined in the JDBCConnectorGroup group.

1 namespace eval JDBCConnectorWithMySqlDemo {
2  set inherits {
3  JDBCConnectorGroup *
4  ConnectToMySqlSuite {
5  SpecifyDriverClassNameDemo SpecifyConnectUrlDemo
6  }
7  }
8 }

This could be shortened to

1 namespace eval JDBCConnectorWithMySqlDemo {
2  set inherits { JDBCConnectorGroup * ConnectToMySqlSuite Specify* }
3 }

The Specify* pattern will be expanded to SpecifyDriverClassNameDemo and SpecifyConnectUrlDemo.

Display Dependency Relations using Graphviz

The demo cases and their dependencies to each other can be displayed in a graph using the Graphviz software. The TNT can create files in the dot language that can be converted to varions graphics formats or directly viewed with the zgrviewer software.

Provide the options array to the executeDemoSuite command and set the dot option. See executeDemoSuite.

How to interpret Test Results

Test results are recorded in the testResults array the name of which is passed to the commands as a parameter. Demo cases are assigned so called four-letter-status-words out of the following:

  • FAIL - A test executed with error
  • DAMN - A precondition test threw an error
  • ARGH - A precondition is not met
  • OUCH - A test threw an error
  • OUPS - The verification code threw an error
  • GOOD - No test executed with an error or failed assertion
  • DEPS - A test can't execute because dependencies didn't complete successfully
  • SKIP - A test is not executed as filtered out by filter pattern
  • WAIT - A test has not yet been executed (this is here for the sake of completeness, you will normally never see this status in the output)

Preconditions

The precondition procedures can be used to define preconditions that must be met before the code defined in the code procedures get executed. The canExecuteDemoSuite can then be called prior to running any test in order to check if there are unmet preconditions. This is for example useful to test if test data required to execute the demo suite is available. If it is not the test script may not even offer the possibility to execute the demo suite

For this to work the code in a precondition procedure must not depend on results from code to be executed as a test. Only then all precondition procedures can be executed to verify if the demo suite can be executed.

Read more (including examples) under precondition proc and canExecuteDemoSuite command.

Angle Bracket Expressions

All procedures defined in a demo case such as code, precondition, verify or examples may contain placeholders of the form <%= SCRIPT%>. The SCRIPT is a piece of Tcl code that is executed when the code is retrieved from the body of the procedure. The result of the execution replaces the placeholder. This can be used for example to avoid code duplication.

Hiding Lines from Output

If you want lines in the code procedure to not appear in the representation used for documentation purposes you can suppress them with the following markers:

  • Enclose one or multiple line in markers
    1 #HIDE ON#
    2 ... lines to be hidden ...
    3 #HIDE OFF#
  • Add a marker to the end of a line
    1 line to be hidden; #HIDE#

Lightweight Markup Language (LWL)

The htmlWriteLessons command produces HTML output from text placed into lessons. The lessons are parsed by a simple markup processor that translates the markup into HTML elements.

The following markup elements are supported:

  • Text between apostrophes will be formatted as code, e.g.

    The value is 'true' → The value is true

  • Text between asterisk will be output in bold font, e.g.

    Click on *File* → Click on File

  • Text between double pairs of angle brackets will be output in italic font, e.g.

    This is called a <<demo case>> → This is called

    a demo case
  • Two dashes and an angle bracket will be output as a right arrow, e.g.

    Go to File –> New ... → Go to File → New ...

  • A single dash and an angle bracket followed by the name of a demo case creates a link in the output document, e.g.

    See ->FindBomHeader → See <a

    href="#::DemoSuite::FindBomHeader">Find the header of a Bill Of Material (BOM)
  • The pattern --! Caution ! on a single line followed by any number of dashes marks the beginning of highlighted text. The end of the highlighted text is marked with a single line consisting of at least six dashes, e.g.:

    --! Caution !–—
    NOTE THAT ...
    ——————

    is rendered as
NOTE THAT ...
  • A line beginning with an asterisk denotes a list item
  • It is possible to create simple tables in the output document, e.g.
    +=================+==================+
    |contextType | type of stucture |
    +=================+==================+
    |MEProductContext | Bill of Material |
    +-----------------+------------------+
    |MEPlantContext | Plant |
    +-----------------+------------------+
    |MEProcessContext | Bill of Processes|
    +=================+==================+
    is rendered as
    contextType type of stucture
    MEProductContext Bill of Material
    MEPlantContext Plant
    MEProcessContext Bill of Processes

Function Documentation

◆ canExecuteDemoSuite()

T4X::TNT::canExecuteDemoSuite   namespace ?optionsVar?  

Test whether all preconditions defined in a demo suite are met.

If you are interested in more details you can use the executeDemoSuite command with the execute option set to false and extract the details from the result array.

  • Example:
    1 if {[::T4X::TNT::canExecuteDemoSuite ::WsdlImportDemo]} {
    2  puts "Test data found"
    3  set action TEST
    4  set actions [concat [list {TEST Execute automatic test}] $actions]
    5  set usageHint [concat {TEST} $usageHint]
    6 } else {
    7  puts "Cannot execute without test data"
    8  set action TEACH
    9 }
Parameters
namespacethe Tcl namespace representing the demo suite
optionsVar(optional) name of an array variable from which to read further options. Supported options are given with the executeDemoSuite command.
Returns
true if all preconditions are met, false if any is not met.

References executeDemoSuite().

◆ executeDemoSuite()

T4X::TNT::executeDemoSuite   namespace testResultsVar ?optionsVar?  

Execute demo suite as a test.

If the optionsVar parameter is given it is interpreted as the name of an array that may contain the following entries:

  • executionContext - namespace inside which the tests are executed; defaults to the namespace given as the first argument
  • patterns - List of patterns to be applied to the names of demo cases (the names of the namespaces) to select which demo cases to process; defaults to the empty string in which case all non lazy demo cases are selected.
  • dot - If set to true a directed graph with the demo cases as nodes and the dependencies as edges will be written to a file. The name of the file is stored in the test result under the dotFileName key. It can be overridden by setting the dotFileName option. By default dot files are placed in the tmp/dot folder in subdirectories named after the demo cases. If you also set the execute option to false no tests will be executed.
  • dotFileName - Override the name of the file to which dot files are written. See dotOption.
  • dot.showHidden - If set to true also implicit demo cases will appear in the generated dot graph. See dotOption.
  • showHidden - If set to true also display the output and test results of hidden demo cases.
  • testPrecondition - If set to true test if all preconditions are met and write the result into the preconditionsMet field of the result array; defaults to false.
  • execute - If set to false no demo case will be tested. This is used in conjunction with testPrecondition to only check the preconditions or can be used to create dot graphs without executing tests. See dotOption
  • testDataRoot - The path name of the folder where the TNT framework expects test data. Defaults to 'var/testdata' inside the T4x installation. The test data is used for comparisons with Assert::assertTextFilesEqual.
  • outputCodeUnderTest - If set to true the code that is being tested will be output. This is useful to verify if the angle bracket expressions" are expanded in the expected way.
Parameters
namespacethe Tcl namespace representing the demo suite
testResultsVarname of an array variable into which the test result is recorded
optionsVar(optional) name of an array variable from which to read further options. Supported options are given above.

Referenced by canExecuteDemoSuite(), and executeTests().

◆ executeTests()

T4X::TNT::executeTests   args  

Execute demo suite as a test (deprecated).

Deprecated:
Use executeDemoSuite instead as it supports the preferred way of passing in options.
Parameters
namespacethe Tcl namespace representing the demo suite
executionContextnamespace inside which the tests are executed
testResultsVarname of an array variable into which the test result is recorded
patterns(optional) list of patterns to be applied to the names of demo cases (the names of the namespaces) to select which demo cases to process. The string match command is used for this and case is ignored.

References executeDemoSuite().

◆ formatTestReport()

T4X::TNT::formatTestReport   testResultsVar  

Format the test results into a list of lines.

Parameters
testResultsVarname of an array variable containing the test results as produced by the executeDemoSuite command.

Referenced by logTestReport(), and putTestReport().

◆ getNetResult()

T4X::TNT::getNetResult   testResultsIn  
Parameters
testResultsInthe name of the Tcl array containing the test results.
Returns
one of the two four letter status words GOOD or FAIL indicating whether all demo cases succeeded or failed.

References succeeded().

◆ getNonGood()

T4X::TNT::getNonGood   testResultsIn  

Returns the list of demo cases that did not complete with GOOD.

◆ getStatus()

T4X::TNT::getStatus   testResultsIn demoCase  
Parameters
testResultsInthe name of the Tcl array containing the test results.
demoCasethe namespace name of the demo case.
Returns
the four letter status word for the given demo case.

◆ htmlCloseFile()

T4X::TNT::htmlCloseFile   channel ?optionsVar?  

Close an HTML file opened to receive the documentation to be generated through the htmlWriteLessons command.

Parameters
channelidentifier representing the HTML file
optionsVar(optional) name of an array variable from which to read further options.

◆ htmlOpenFile()

T4X::TNT::htmlOpenFile   htmlOutputFileName ?optionsVar?  

Open an HTML file to receive the documentation to be generated through the htmlWriteLessons command.

Parameters
htmlOutputFileNamefull path of the HTML file
optionsVar(optional) name of an array variable from which to read further options.
Returns
a channel identifier representing the HTML file

◆ htmlWriteLessons()

T4X::TNT::htmlWriteLessons   outChannel namespace ?optionsVar?  

Derive documentation from a demo suite and write it to an HTML file.

Parameters
outChannelidentifier representing the HTML file
namespacerepresenting the demo suite
optionsVar(optional) name of an array variable from which to read further options.

References writeLessons().

◆ logTestReport()

T4X::TNT::logTestReport   testResultsVar ?logChannel?  

Output test results using the tpwrite command.

The log lines are assigned a message type according to the status of the tests.

Parameters
testResultsVarname of an array variable containing the test results as produced by the executeDemoSuite procedure.
logChannel(optional) identifier of the log file to write to.

References formatTestReport(), and tpwrite().

◆ putCode()

T4X::TNT::putCode   namespace ?optionsVar?  

Generate code from the demo suite and output the code using the puts command.

The generated code may be copied into real mappings but may have to be reworked afterwards.

Parameters
namespacerepresenting the demo suite
optionsVar(optional) name of an array variable from which to read further options.

References PutTitleWithPrefix().

◆ putLessons()

T4X::TNT::putLessons   namespace ?optionsVar?  

Output the title, lesson and code parts of demo suite using the puts command.

The demo cases are taken from the namespace from which this command is called.

Parameters
namespacerepresenting the demo suite
optionsVar(optional) name of an array variable from which to read further options.

References PutTestSpecs().

◆ putOverview()

T4X::TNT::putOverview   namespace ?optionsVar?  

Output the title, and code parts of demo suite using the puts command.

Parameters
namespacerepresenting the demo suite
optionsVar(optional) name of an array variable from which to read further options.

References PutTestSpecs().

◆ putTestReport()

T4X::TNT::putTestReport   testResultsVar  

Output test results using the puts command.

Parameters
testResultsVarname of an array variable containing the test results as produced by the executeDemoSuite procedure.

References formatTestReport().

◆ setProperties()

T4X::TNT::setProperties   fullName args  

Assign properties to a demo case and set their values.

Parameters
fullNamename of the demo case
argslist of property names and values

◆ splitCode()

T4X::TNT::splitCode   text width  

Simple command to split long code lines

Parameters
textcode to split
widthmaximum width of the code lines. If the value is -1 the input text is returned.

◆ succeeded()

T4X::TNT::succeeded   testResultsIn  
Parameters
testResultsInthe name of the Tcl array containing the test results.
Returns
true if all demo cases succeeded or false if at least one failed.

Referenced by getNetResult().

◆ writeLessons()

T4X::TNT::writeLessons   writer namespace ?optionsVar?  

Derive documentation from a demo suite and write it with the given writer.

Parameters
writernamespace of the writer to use
namespacerepresenting the demo suite
optionsVar(optional) name of an array variable from which to read further options.

References PutTestSpecs().

Referenced by htmlWriteLessons().