I think the same! I thought about taking this as my task:
_______________________________________________________________
1. Firstly bringing all tests to tcltest 2.0 syntax

a great mess with the tcltest package.  (Rolf Ade)

2. Eliminating situations when the test fails because there were made wrong assumptions.
_______________________________________________________________

The design of tests for the layout algorithms has got to be something of a
black art, since you've got to figure out how to avoid brokenness from
the environment and determine how to test what was intended instead of
conducting experiments on what is actually done... Tricky!  (DKF)

Hih:P well... so now I'm both tricky! and... a bit confused: now I'm not sure - do I think right, that trying to deal with:

The real problems with Tk's test suite are that it is highly
dependent on the platform that you test on (i.e. it's clean on only one
or two machines in the whole world!) and that it often doesn't check for
what *should* be the answer, but rather just what *is* the answer.
Fixing those things (or at least making a good step on them) will be a
good task. (DKF, some time ago, during application time)

As for

2) There are tests that fail, which do imply an actual bug in Tk, but don't
clearly point to just where that bug is.

Q: I'm not sure what I should do in this case... Is it possible to give an example of this situation and it's solution?



 
I've directed my first steps of bringing all tests to tcltest 2.0 toward message.test, as I was advised to, and button.test. I'd really appreciate any comment on that, as this are my toddler steps.

>4. Wiki page
>I added my project's wiki page where I put my ideas (marked(i)) and questions (marked(?)). (me)

 

I'm only a novice in Tcl/Tk and giving me the right to commit on SF could be pretty huge for me:P Maybe overwhelmingly huge; I think I should first get into Tcl/Tk, gain some experience, survive a flux of criticism, grind my style... and then, possibly, I'll be prepared :P

Some time ago I created svn for the project. I thought about sending there my code until it's not verified/accepted.
This is where I've put the current code (message.test and button.test)
http://svn.assembla.com/svn/TkTests/
(button.test is not complete, but I'd like to know if it tends toward good direction)
(it took me unbelieveably long to create this mail and this is why I have done so little progress :P).
I thought that maybe this thread would be a proper place to comment...
so to give the outline:


GENERALLY: (main changes, assumptions; questions (Q))
(I'd like to describe even tiny points to be sure I don't miss the idea.)

1. Global dependences
(- so the main goal to destroy)
I removed all global assumptions. Every widget created - is created and destroyed in the a case. In button.test there was also need to unset the buttons' variables. There're are no global variables, dependences and interferences. I resigned from helper procedures for setup.

1.1 -setup
I don't have certainty which pattern is the most suitable? (During implementing I was often making up my mind so setups are not yet consistent - there are in one of three folloing patterns - I'll fix it after choosing the right form.)

I was suggested by tcltest man page where
    test example-1.1 {test file existence} -setup {
            set file [makeFile {} test]
} -body {
            file exists $file
} -cleanup {
            removeFile test
} -result 1
but tcltests (from tcl test suite) that're written in tcltest 2 prefer the third idea.
Idea1:
# putting into body everything but result; I suppose it's a bad idea:P If there's an error we know too little
    test message-1.1 {configuration option: "anchor"} -setup {
        message .m -borderwidth 2 -highlightthickness 2 -font {Helvetica -12 bold}
        pack .m
        update
        .m configure -anchor w
} -body {
        .m cget -anchor
}
Idea2:
# the features important for the result are put into body. But sometimes it could be
# needed to know p.e. what widget was created
    test message-1.1 {configuration option: "anchor"} -setup {
        message .m -borderwidth 2 -highlightthickness 2 -font {Helvetica -12 bold}
        pack .m
        update
} -body {
        .m configure -anchor w
        .m cget -anchor
}
Idea3
    test message-1.1 {configuration option: "anchor"} -body {
        message .m -borderwidth 2 -highlightthickness 2 -font {Helvetica -12 bold}
        pack .m
        update
        .m configure -anchor w
        .m cget -anchor
}
Q:  Which pattern is the most suitable?
Q:  Do pack widgets? In the original tests they're sometimes packed. Keep that the same, pack always or resign from displaying?


1.2 Configuring widget
In the originals there were added options to database. In fact, they had no influence on any test result. They were, as described in button.test
    # Create entries in the option database to be sure that geometry options
    # like border width have predictable values.
    option add *Button.borderWidth 2 [...]
Q:  Keep those options set while creating a widget? (they don't have any influence)

1.3 cleanup - destroy
I destroy widgets even if they have no right to be created.
test button-2.7 {ButtonCreate - bad window name} -body {
    button foo
} -cleanup {
    destroy foo
} -returnCodes {error} -result {bad window path name "foo"}
Q:  Do so?

1.4 cleanup - unset
I've noticed that in cleanup variables should be unset, as
p.e. when I run button-3.55 and  unsetting in button-3.54 wasn't done
- it was passed  when I run as a single test case
- it failed when I run all tests,
Q: Is that thinking correct? or maybe do unsetting and destroying, (with catching errors) in the setup?


2. Test cases
2.1 I split the test cases that both catch an error and obtain informations (like winfo, errorInfo) to detect an error by -returnCodes.
Previous:
    test message-2.3 {Tk_MessageObjCmd procedure} {
        list [catch {message .s -gorp dumb} msg] $msg [winfo child .]
    } {1 {unknown option "-gorp"} {}}
Idea:
    test message-2.4 {Tk_MessageObjCmd procedure} -body {
        message .s -gorp dump
    } -returnCodes {error} -result {unknown option "-gorp"}
    test message-2.5 {Tk_MessageObjCmd procedure} -body {
        catch {message .s -gorp dump} 
        winfo child .
    } -result {}
Q:  Appropriate?

2.2 Checking if no error
There're some test cases that only expect the return code that should be {ok}. However, I need to have a -result to compare with. I've thought about two options (plus one rather pointless). IMHO as the secnd one's construction is analogical to the ones that return an error code, I'd use that one. Hovever, I don't know if
    -match {glob} -result {*} ;# means result does'n matter
is any sensible.
The third Idea would be simply setting an option like in tests 1.*
Previous:
    test button-4.7 {ButtonWidgetCmd procedure, "cget" option} {
        catch {.l cget -disabledforeground}
    } {0}
Idea1:
    test button-3.7 {ButtonWidgetCmd procedure, "cget" option} -setup {
        label .l
    } -body {
        catch {.l cget -disabledforeground}
    } -cleanup {
        destroy .l
    } -result {0}
Idea2:
    test button-3.7 {ButtonWidgetCmd procedure, "cget" option} -setup {
        label .l
    } -body {
        .l cget -disabledforeground
    } -cleanup {
        destroy .l
    } -returnCodes {ok} -match {glob} -result {*} ;# means result does'n matter
Idea3:
The last idea is to set an otion value and expect it in the result, but then it would be nothing but 1.* {configuration option: ""} test case.

Q:  What to choose?


2.3 Tests 1.* {configuration option: ""}
To obtain the result I use {cget -option} instead of {lindex [.m configure -anchor] 4} "as the tests are of the options and not of the configuration machinery itself." (DKF)
Though in the later test case there is cget option checking: as this is done before, but there's no lindex [.m configure -option] 4 checking, this time I used configure instead of cget.
This is the test case I'm describing:
    test button-4.6 {ButtonWidgetCmd procedure, "cget" option} {
        .b configure -highlightthickness 3
        .b cget -highlightthickness
    } {3}

2.4 test button-1.* {configuration option) - constraint
constraints testImageType is not needed in most test-1.* cases


3. Descrptions
Q:  As there're the same test cases in diffrent tests, I thought about unifying the way that cases are described. Only oes that matter? (I haven't done that yet).


Ania:)

P.S.

P.S.2

As we often observe in
the chatroom, the test suites include both tests and experiments.  Only
the tests are really useful.  There's little point in tidying up the
experiments.  Much effort for little value.