Contents:
test
directory.
Test
menu which has choices for the tests arranged
by directory.
$TYCHO/kernel/basic/test/testStack.itcl
with Tycho and then evaluate the contents of the file with
the Evaluate
choice from the File
menu
(C-x C-r
).
$TYCHO/mk/tycommon.mk
file automagically generates two Itcl files:
all.itcl
*.itcl
files in the
current directory.
alltests.itcl
makefile
.
make sources
, you can open up either of these files
and then evaluate it, which will run all the tests in that directory.
$TYCHO/kernel/gui/test/alltychotests.tcl
alltychotests.tcl
will run all the alltests.itcl
files. $TYCHO/makefile
has two rules:
make alltests
tycho
make alltests.ptiny
tycho -ptiny
make
, you can try
source [file join $TYCHO kernel gui test alltychotests.tcl]
test
directory and typing make
from a shell. To try this out,
click on the Tcl code below:
::tycho::execModal {make} "[file join $TYCHO kernel gui test]"
$TYCHO
) directory with the command: make tests
Test Template
under the Special
menu. This menu choice loads the file
$TYCHO/edit/textedit/templates/testTemplate
into the Itcl editor.
The file $TYCHO/kernel/gui/test/testDefs.tcl
defines the Tcl proc test
.
test
takes four arguments:
foo-1.0
testDefs.tcl
file and then runs one test. The code below
has the incorrect value return results to be compared against, so the
test suite properly indicates that the test failed.
if {[string compare test [info procs test]] == 1} then { source [file join $TYCHO kernel gui test testDefs.tcl] } {} test testExample-1.1 {This is the first test example, it does very little} { catch {this is an error} errMsg1 set a "this is the value of a" list $errMsg1 $a } {{invalid command name "this"} {this is NOT the value of a}}
test
directory.
The EditItcl class has a test file template menu choice under
the Special
menu. The template is located at
$TYCHO/edit/textedit/templates/testTemplate.itcl
It is better to have many small test files as opposed to a few
large test files so that other developers can quickly find the tests
for the class they are working with. Usually tests for the class
Foo
are found in the file test/testFoo.itcl
See $TYCHO/kernel/gui/test/testGraph.itcl
for an example test file.
Each test file should have the following parts:
test
.
For example, if we were testing the Tcl foo
command, then
the file would be named testFoo.itcl
. The extension of the file
is either .tcl
or .itcl
:
Most of the tests are .itcl
files.
package require tycho.util.tytest
#set VERBOSE 1
############################################################################ #### Foo test Foo-1.1 {Test out Foo} { } {}
It is up to the author of the tests as to whether each individual test does all the set up necessary. If each test is atomic, then it makes it easy to highlight the text of an individual test and run it. If lots of tests are sharing common setup, then using a separate procedure to do setup might help. On the negative side, atomic tests usually are longer and have more complicated return results.
The problem is that when a model dialog box comes up, execution
halts, so during testing the user would need to know what button to
hit. To work around this, the
Dialog::wait
procedure (which is user to wait for
the result of all modal
dialog boxes in Tycho)
checks for the TY_TESTING
global variable, to see if it has been called from within
a test script. If so, then Dialog::wait
will not
actually make the dialog model but will do
one of two things:
TY_TEST_MODAL
exists
and is not null, then this is taken to be a list of
scripts. It will remove the first script from this list,
and evaluate it at the global scope with the name of the dialog box
substituted for every occurrence of the string %0
. The
script should invoke methods of the dialog box to insert
data into the dialog and invoke buttons, as a user would
in normal usage. The return result from the call to
Dialog::wait
will be the same as if
a user had invoked those operations and closed the modal
dialog. Because Dialog::wait
removes
the script from TY_TEST_MODAL
, successive calls
to Dialog::wait
execute each script in the list
in succession, allowing tests to easily simulate user input
from a complex succession of dialog boxes.
TY_TEST_MODAL
does not
exist or is null, then Dialog::wait
just returns
the name of the dialog box.
For example, the
$TYCHO/kernel/gui/test/testWidgets.itcl
script includes a test for YesNoQuery
:
if {[string compare test [info procs test]] == 1} then {
source $TYCHO/kernel/gui/test/testDefs.tcl
} {}
test YesNoQuery-2.1 {Test the modal ::tycho::askuser proc} {
set TY_TEST_MODAL {
{
%0 invoke yes
}
}
::tycho::askuser "Are you awake?"
} 1
Note that TY_TEST_MODAL
must be a list of
scripts, even if the list contains only one script. Here is
another sample test that simulates the user interaction to
a series of two dialog boxes.
The code being test is an example from
the
Dialog Classes tutorial:
if {[string compare test [info procs test]] == 1} then {
source $TYCHO/kernel/gui/test/testDefs.tcl
} {}
test sampleTest-1 {Test a series of modal dialogs} {
# Set the series of response to the dialogs. The
# first one clicks on the Yes button, the second clicks
# on the OK button. Note that comments
set TY_TEST_MODAL {
{
# This script simulates pressing the Yes button
# of the YesNoQuery box
%0 invoke yes
}
{
# This script simulates pressing the OK button
# of the Message box invoked by :tycho::inform
%0 invoke ok
}
}
# Now execute the code that creates the modal dialogs.
# In this case, the result is null.
::tycho::YesNoQuery .z -text {Are you awake?}
if [::tycho::Dialog::wait .z] {
::tycho::inform {You said yes!}
} {
::tycho::inform {Then how did you click on the No button?}
}
} {}
event generate
event generate
command is very handy for testing
widgets by generating an event in a window as if it had come from the
window system.
The tests below are doing an <Enter>
and
<Leave>
of a button and checking the text placed
into a status bar:
update test ButtonBox-3.3 {Enter button and check status bar} { event generate [.bb component buttonfoo] <Enter> .sb get } {The Foo button} update test ButtonBox-3.4 {Leave the button} { event generate [.bb component buttonfoo] <Leave> .sb get } {}
make
in a test directory that contains
tests written in Tcl for testing Java classes, then the 'right thing'
should just happen. The Java testbed does have a few differences:
make test_jsimple
rule
tclsh
binary
that can load the Tcl Blend extension
alljtests.tcl
file
Tcl Blend allows us to instantiate objects in a class and call public
methods. We use Tcl Blend and the standard Tcl test bed to create tests.
In the example below, we call java::new
to create an
instance of the Java NamedObj
class. We can then
call public methods of NamedObj
by referring to the
Java object handle $n
:
test NamedObj-2.1 {Create a NamedObj, set the name, change it} { set n [java::new pt.kernel.NamedObj] set result1 [$n getName] $n setName "A Named Obj" set result2 [$n getName] list $result1 $result2 } {{} {A Named Obj}}
test
subdirectory of the directory where the Java class
is defined.
For example, if we are testing NamedObj.java
, then
the Tcl test file should be at test/NamedObj.tcl
.
Tcl Blend provides a Tcl procedure called java::info
which returns information about an instance of a Java class.
$TYCHO/kernel/gui/test/testDefs.tcl
defines the getJavaInfo
Tcl proc, which takes a Java object
handle and returns a string that describes the object's fields, methods
constructors, and superclass.
Each Java class should have a Tcl test that calls getJavaInfo
so that if the Java class definition changes, then the test will fail.
This will hopefully prompt the developer to write a test for the
changed feature.
If a test fails because of changes in the values returned by
getJavaInfo
, then the way to fix the test is to run
the test and grab the strings actually returned and substitute it back
into the test file. Of course, you should write tests that cover any
changes reported by getJavaInfo
.
Here's how to review the test suite code coverage:
cd $TYCHO/java/pt/kernel make jsallThe
jsall
makefile rule does the following:
jsreport
or javascope
jsreport -dbsummary
make jsrestore
.
make jsrestore
There are two ways to do this.
IFLUSHCLASS
option will flush out the coverage
information for the current class at the end of each method.
IFLUSH
option will flush out all the coverage
information at the end of each method.
IFLUSH
will take more time than using
IFLUSHCLASS
.
The jsintr
options are set by consulting the following
resources in order.
$HOME/javascope.properties
./javascope.properties
in the current directory.
/*jsoptions: ...*/Embedded comment options can be set more than once in a file. Embedded comment options are in effect until is the option is changed by another embedded comment option.
jsinstr
.
jsinstr
documentation for details.
I tried to use Tcl Blend to call a dummy Java method that flushes the
database using an embedded comment, and then call that method before
exiting.
Here's how I attempted to flush the database using a dummy Java method.
I created the JavaScopeFlush
class:
public class JavaScopeFlush { /*jsoptions:IFLUSH=true*/ public static void flush() { } /*jsoptions:IFLUSH=false*/ }
Ran jsinstr
on JavaScopeFlush.java
I then tried to call this method with:
java::call JavaScopeFlush flushUnfortunately, it looks like embedded comments are broken.
For more information, see the JavaScope FAQ.
ftp://ftp.cre.canon.co.uk/pub/weblint/weblint.tar.gz
To run weblint
:
cd $TYCHO make weblint
htmlchek
also checks for bad links. The
htmlchek
output is a little hard to read, so we tend to
use weblint
for checking individual files.
htmlchek
can be obtained from
ftp://ftp.cs.buffalo.edu/pub/htmlchek/
The best way to run htmlchek
is to create a sample
distribution, create the files in the codeDoc
directory
and then run htmlchek
cd /users/ptdesign/adm/gen-latest; make htmlchek
TYCHO
to point to the test distribution:
setenv TYCHO /users/ptdesign/adm/dists/tycho-latest cd $TYCHO
make install
. This will make the Itcl HTML docs
twice, which will populate the doc/codeDoc
directories.
You need to make the Itcl HTML docs twice so that the cross references are
correct.
make htmlchek
All of the references in htmlchekout.HREF
that point
to .html
files should be checked. References to non-HTML
files appear in htmlchekout.HREF
because the non-HTML
files were not included in the list of files that
htmlchek
ran on. One quick way to search all the the *.html
files is
cd $TYCHO grep mystring `find . -name "*.html" -print`
cd $TYCHO spell `find . -name "*.html" -print`You can spell check an individual HTML file by using the HTML editor built-in spell checker under the
Edit
menu.
<TCL> . . . <TCL>
tags. In the Tycho HTML viewer, when the contents of these tags are
moused on, the embedded Tcl code is executed.
To test all of the embedded Tcl, the script
$TYCHO/adm/bin/chktclpre
will generated a
tclpre.html
file that contains all of the embedded Tcl.
This script is not shipped with Tycho.
After running chktclpre
, start up Tycho, view
tclpre.html
and mouse on each block of embedded Tcl code.
Note that some blocks depend on the widgets created in earlier blocks.
If you run into problems, you can follow the hyperlink in
tclpre.html
to the source HTML file.
~ptdesign/adm/copyright/chkq $TYCHO
to print out
the names of files that might have bogus %Q%
values.
Then run ~ptdesign/adm/bin/sccsadmin
on each file that
has no value for %Q%
substituted in.
make realclean
tclIndex
files and the files in
doc/codeDoc
. The reason to remove the
codeDoc
files is so that we don't ship HTML files for any
classes that have been removed.
make install
tclIndex
files and the
doc/codeDoc
files.
make checkjunk
adm/bin/chkgifs
$TYCHO/bin/tycho
script
can be tested with the $TYCHO/kernel/gui/test/chktycho
script.
This script calls tycho
with all the various
combinations of command line arguments. chktycho
adds a
line to ~/.Tycho/tychorc.tcl
so
that tycho
is exited after a few seconds. This allows
the script to test many invocations of tycho
without user
intervention. However to test the -debug
option, the
user must type cont
in the gdb
window.