7 Jul 10:56
Re: Updating Tktest suite - GSoC project
From: Donal K. Fellows <donal.k.fellows@...>
Subject: Re: Updating Tktest suite - GSoC project
Newsgroups: gmane.comp.lang.tcl.core
Date: 2008-07-07 08:56:20 GMT
Subject: Re: Updating Tktest suite - GSoC project
Newsgroups: gmane.comp.lang.tcl.core
Date: 2008-07-07 08:56:20 GMT
Ania Pawelczyk wrote: > 1. namespaces > -should I create that? and names p.e. namespace eval testbutton. It's > recommended on the manpage, but I haven't noticed any recently updated > tcl or tk test using that. I wouldn't bother.Adding namespaces slightly improves the separation, but not by very much, and it makes much of the coding of the tests themselves less clear (as Tk prefers global variables). > 2. Which convention of package require tcltest 2.1 to choose? And > tcltest 2.1 or 2? > if {[lsearch [namespace children] ::tcltest] == -1} { > package require tcltest 2.1 > namespace import -force ::tcltest::* > } > or > package require tcltest 2.1 I'd just do: package require tcltest 2 ;# or 2.1 or whatever namespace import -force ::tcltest::* Trying to avoid the trivial amount of work involved in doing the above (which is what that [lsearch] stuff is about) is silly given that we're testing Tk, which does some very expensive operations indeed.
> 3. For test 1.* {configuration option} which have all the same setups - > which form to use? > proc createButton {} { > button .b -borderwidth 2 -highlightthickness 2 -font {Helvetica > -12 bold} > pack .b > update > } > [...] > } -setup { > createButton > .b configure -bd 4 > } > > or > proc createButton {option value} { > button .b -borderwidth 2 -highlightthickness 2 -font {Helvetica > -12 bold} -$option $value > pack .b > update > } > [...] > } -setup { createButton bd 4} > (or none of them:P) The first is better as it is clearer. I might even go for this: test .... -setup { button .b -borderwidth 2 ... pack .b update } -body { ... If you really want to use a helper procedure, do this: proc createButton args { button .b -borderwidth 2 ... {*}$args pack .b update } ... -setup { createButton -borderwidth 4 } ... You'll have to pick which you want to do yourself. > 4. For test 1.* {configuration option: ""} in the body > I thought abut using > .m cget -anchor > instead of > lindex [.m configure -anchor] 4 > (sorry if I miss the concept :P) Sounds fair enough to me, as the tests are of the options and not of the configuration machinery itself. That particular "idiom" dates from a long way back, before the cget method was added. FWIW, the cget method was added as part of Tk 4.0, so as you can see those tests have needed some work for a very long time! Donal. ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08
Adding namespaces slightly improves the
separation, but not by very much, and it makes much of the coding of the
tests themselves less clear (as Tk prefers global variables).
> 2. Which convention of package require tcltest 2.1 to choose? And
> tcltest 2.1 or 2?
> if {[lsearch [namespace children] ::tcltest] == -1} {
> package require tcltest 2.1
> namespace import -force ::tcltest::*
> }
> or
> package require tcltest 2.1
I'd just do:
package require tcltest 2 ;# or 2.1 or whatever
namespace import -force ::tcltest::*
Trying to avoid the trivial amount of work involved in doing the above
(which is what that [lsearch] stuff is about) is silly given that we're
testing Tk, which does some very expensive operations indeed.
RSS Feed