tcllib-devel

[Tcllib-devel] Writing tests - how?

[Lars H. <Lar...@re...>]

Apologies if this has been discussed before (at least I'm certain I've 
been bothered by this before), but a search on the SF mail archives did 
not find anything within the last year and a half or so.

Basic problem: The tcllib README states

  * the module should have both documentation ([*]) and a test suite
    (in the form of a group of *.test files in the module directory).
  * the module must have either documentation or a test suite.  It can
    not have neither.

and README.developer continues

  * If available the testsuite(s) should use 'tcltest' and the
    general format as used by the other modules in Tcllib
    (declaration of minimally needed Tcl, tcltest, supporting
    packages, etc.). The file(s) should have the extension
    '.test' for SAK to recognize them.

but what does this mean concretely? I'd interpret it as saying that 
e.g. foo.tcl should come with foo.test, where the latter looks like:


package require Tcl 8.4 ; # Declaration of minimally needed Tcl
package require tcltest 2 ; # Ditto tcltest
package require bar 1.3.2 ; # Supporting package

# Now follows the test(s). (Currently, there is only one.)
tcltest::test foo-1.1 "Testing foo" -body {
    foo
} -result "baz"


but I rather doubt this would work; for one, the foo package itself 
doesn't seem to be loaded. Is that perhaps the "etc." in 
README.developer ;-), or is there rather some automagic [source]ry 
going on? More information seems to be required. (Yes, I will find out 
below that the above probably doesn't refer to [package require] at 
all, but rather to [testsNeedTcl] and friends.)

A tcllib contributor might of course at this point choose to just 
duplicate whatever is done in existing .test files in tcllib, but 
doing-without-understanding is not a strategy I'm comfortable with. 
Besides, when I /have/ picked modules at random and looked at their 
.test files, I haven't come across anything that looked like a 
boilerplate test file.

So, I took a look around the CVS archive, in hunt for better 
documentation. There is for example a devdoc directory 
(http://tcllib.cvs.sourceforge.net/tcllib/tcllib/devdoc/) -- maybe this 
contains more information on the matter? Sadly, it doesn't. Also, most 
of the information therein seems to be rather old (even if some files 
were modified 9 months ago). What else is there?

There is also a support/devel directory, which contains all.tcl and sak 
  -- since this is the software canonically running the tests, maybe 
this is where one might find some documentation on the matter? Sadly, 
no. There are several help.txt files, but those only contain 
interactive help messages from the sak application, so the only actual 
documentation I can find therein is for the embedded pregistry package. 
Nothing to help with test files...

The mail achive search did however turn up a mention of 
devtools/testutilities -- where might this be found? As it turns out, 
devtools is a *module* in the CVS repository 
(http://tcllib.cvs.sourceforge.net/tcllib/tcllib/modules/devtools/), 
although it doesn't get installed as a module (only natural, as it has 
neither documentation nor test suite; this is beginning to feel like a 
pattern).

A lot of what is in devtools/ looks very interesting:

   * testutilities.tcl:[useLocalFile] to make sure I'm testing the 
version of my package matching the test rather than some random older 
version I happen to have installed.
   * coserv.tcl (for later, testing an IPC package I'm working on)

but then there's the matter of missing documentation, and questions it 
should have answered:

   * Should one use [useLocalFile], [useTcllibFile], [useLocal], or 
what? When and why?
   * How are these commands supposed to be made available? When can one 
rely on them?

What is currently available /may/ of course be interpreted as "well, 
just copy and modify pop3.test". I suppose this will work (many have 
probably done that) but already the first commmand

source [file join \
  	[file dirname [file dirname [file join [pwd] [info script]]]] \
  	devtools testutilities.tcl]

there is enough to make me shun away. Surely there should be a better 
way to do this?


Lars Hellström

Re: [Tcllib-devel] Writing tests - how?

[KATO K. <k.k...@gm...>]

[tcltest] is not a module of tcllib but the more standard command.
Therefore, it can be said that it naturally is not written as a
document of tcllib.

About how to write a test script:
A source code is very often a good document especially to write one.
testsuits written by me may be consulted.
[modules/yaml/huddle.test, yaml.test]

It can operate as an independent simple-test and operates also as a
series of tests of sak.tcl.

----------------------------------------
$ cd modules/yaml; tclsh huddle.test
or
$ sak test run modules/yaml
----------------------------------------


About [devtools], the author's Mr.Andreas Kupries will reply.

Re: [Tcllib-devel] Writing tests - how?

[Andreas K. <and...@ac...>]

> What is currently available /may/ of course be interpreted as "well,
> just copy and modify pop3.test". I suppose this will work (many have
> probably done that) but already the first commmand

> source [file join \
>   	[file dirname [file dirname [file join [pwd] [info script]]]] \
>   	devtools testutilities.tcl]

> there is enough to make me shun away. Surely there should be a better
> way to do this?

As far as I know, no. This is the standard command to load the common
support code for testsuites in Tcllib. It uses the location of the .test
file to compute the location of the support code and the sourcing it. We
cannot avoid its replication across all testsuites. Stuffing it into a
procedure in the support code will not work, because then you will need the
support code itself to make the support code available. And I do not have
any other ideas. If you have some feel free to tell me.


> Apologies if this has been discussed before

AFAIK no.

>(at least I'm certain I've
> been bothered by this before), but a search on the SF mail archives did
> not find anything within the last year and a half or so.

> Basic problem: The tcllib README states
>
>   * the module should have both documentation ([*]) and a test suite
>     (in the form of a group of *.test files in the module directory).
>   * the module must have either documentation or a test suite.  It can
>     not have neither.
>
> and README.developer continues
>
>   * If available the testsuite(s) should use 'tcltest' and the
>     general format as used by the other modules in Tcllib
>     (declaration of minimally needed Tcl, tcltest, supporting
>     packages, etc.). The file(s) should have the extension
>     '.test' for SAK to recognize them.
>
> but what does this mean concretely? I'd interpret it as saying that
> e.g. foo.tcl should come with foo.test, where the latter looks like:
>
>
> package require Tcl 8.4 ; # Declaration of minimally needed Tcl
> package require tcltest 2 ; # Ditto tcltest
> package require bar 1.3.2 ; # Supporting package

Actually:
	[std command to load testutilities.tcl]

	testsNeedTcl 8.4
	testsNeedTcltest 2

Is the supporting package bar in Tcllib ? If not

	package require bar 1.3.2

otherwise

	support {
	    use bar/bar.tcl bar ;# Assuming that 'bar' is in directory bar under
'modules'.
	}

> # Now follows the test(s). (Currently, there is only one.)
> tcltest::test foo-1.1 "Testing foo" -body {
>     foo
> } -result "baz"
>

>
> but I rather doubt this would work; for one, the foo package itself
> doesn't seem to be loaded. Is that perhaps the "etc." in
> README.developer ;-),

The file README.developer is incomplete, yes.

	testing {
	    use foo.tcl foo
	}

> or is there rather some automagic [source]ry
> going on?

No.

> More information seems to be required. (Yes, I will find out
> below that the above probably doesn't refer to [package require] at
> all, but rather to [testsNeedTcl] and friends.)

> A tcllib contributor might of course at this point choose to just
> duplicate whatever is done in existing .test files in tcllib, but
> doing-without-understanding is not a strategy I'm comfortable with.

Understandable.

> Besides, when I /have/ picked modules at random and looked at their
> .test files, I haven't come across anything that looked like a
> boilerplate test file.

The basic boilerplate is what I have inlined above. Differences come for
packages which have accelerators. Their tests can use the TestAccel
commands, if their accelerator management follows specific lines. Not all do
IIRC, yet.

> So, I took a look around the CVS archive, in hunt for better
> documentation. There is for example a devdoc directory
> (http://tcllib.cvs.sourceforge.net/tcllib/tcllib/devdoc/) -- maybe this
> contains more information on the matter? Sadly, it doesn't. Also, most
> of the information therein seems to be rather old (even if some files
> were modified 9 months ago).

IIRC they are outdated as well.

> What else is there?

>
> There is also a support/devel directory, which contains all.tcl and sak
>   -- since this is the software canonically running the tests, maybe
> this is where one might find some documentation on the matter? Sadly,
> no.

Running the tests doesn't really have to care about the boilerplate setup
and such as long as the test cases themselves are written with 'tcltest',
essentially.

> There are several help.txt files, but those only contain
> interactive help messages from the sak application, so the only actual
> documentation I can find therein is for the embedded pregistry package.
> Nothing to help with test files...
>
> The mail achive search did however turn up a mention of
> devtools/testutilities -- where might this be found? As it turns out,
> devtools is a *module* in the CVS repository
> (http://tcllib.cvs.sourceforge.net/tcllib/tcllib/modules/devtools/),
> although it doesn't get installed as a module (only natural, as it has
> neither documentation nor test suite; this is beginning to feel like a
> pattern).

> A lot of what is in devtools/ looks very interesting:
>
>    * testutilities.tcl:[useLocalFile] to make sure I'm testing the
> version of my package matching the test rather than some random older
> version I happen to have installed.
>    * coserv.tcl (for later, testing an IPC package I'm working on)
>
> but then there's the matter of missing documentation, and questions it
> should have answered:
>
>    * Should one use [useLocalFile], [useTcllibFile], [useLocal], or
> what? When and why?

Yes, all the time.

>    * How are these commands supposed to be made available? When can one
> rely on them?

See the first paragraph, I moved this to the top.


Yes, we have big hole in our developer support there.

I will try to come up with documentation and use you as the guinea pig to
test it on.

Of course, if someone else is willing to write such docs after picking my
brain (= firing questions at me and mangling the answers into a coherent
whole) I will gladly welcome that.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [Tcllib-devel] Writing tests - how?

[Lars H. <Lar...@re...>]

Andreas Kupries skrev:
>> What is currently available /may/ of course be interpreted as "well,
>> just copy and modify pop3.test". I suppose this will work (many have
>> probably done that) but already the first commmand
> 
>> source [file join \
>>   	[file dirname [file dirname [file join [pwd] [info script]]]] \
>>   	devtools testutilities.tcl]
> 
>> there is enough to make me shun away. Surely there should be a better
>> way to do this?
> 
> As far as I know, no. This is the standard command to load the common
> support code for testsuites in Tcllib. It uses the location of the .test
> file to compute the location of the support code and the sourcing it. We
> cannot avoid its replication across all testsuites. Stuffing it into a
> procedure in the support code will not work, because then you will need the
> support code itself to make the support code available. And I do not have
> any other ideas. If you have some feel free to tell me.

Well, what about a small helper package? One could make the above

package require tcllib::testutilities
tcllib::testutilities::init

or something like that. The separate [tcllib::testutilities::init] call 
would be needed to retrieve the [info script] data, although now that I 
think about it, one could (if really devious) embed such a call into 
the [package ifneeded] script as well. An explicit call does however 
have the advantage that one can, if necessary, customise the 
initialisation (no, I don't have a clear use-case for that right now; 
maybe too tired).

What is gained by [package require tcllib::testutilities] is primarily 
that one avoids hardcoding paths (relative paths, yes, but still 
hardcoded paths) into the test files.

Lars Hellström

Re: [Tcllib-devel] Writing tests - how?

[Andreas K. <and...@ac...>]

> Well, what about a small helper package? One could make the above
>
> package require tcllib::testutilities
> tcllib::testutilities::init
>
> or something like that. The separate [tcllib::testutilities::init] call
> would be needed to retrieve the [info script] data, although now that I
> think about it, one could (if really devious) embed such a call into
> the [package ifneeded] script as well. An explicit call does however
> have the advantage that one can, if necessary, customise the
> initialisation (no, I don't have a clear use-case for that right now;
> maybe too tired).

> What is gained by [package require tcllib::testutilities] is primarily
> that one avoids hardcoding paths (relative paths, yes, but still
> hardcoded paths) into the test files.

The price you are paying for this is that you now cannot run the testsuite
anymore if Tcllib is not installed because the package won't be found. Or
using the wrong helper package if some other version of Tcllib is installed.

Running the testsuite of Tcllib without Tcllib installed is IMHO an
important use case during development.

To re-enable execution you have to extend the auto_path, adding again the
path information you do not want to the .test files. Even so it stays
brittle because anybody can intercept this by adding a higher version of the
helper package anywhere on the auto_path.

Extending the auto_path through the setup code done by 'sak test run' ... is
possible, however then the .test files become dependent on this exact tool,
and IIRC there are people who wish to run the tcllib testsuite through their
own tools, and not sak, making such a dependency a bad thing.


--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [Tcllib-devel] Writing tests - how?

[Lars H. <Lar...@re...>]

Andreas Kupries skrev:
>> Well, what about a small helper package? One could make the above
>>
>> package require tcllib::testutilities
>> tcllib::testutilities::init
>>
>> or something like that. The separate [tcllib::testutilities::init] call
>> would be needed to retrieve the [info script] data, although now that I
>> think about it, one could (if really devious) embed such a call into
>> the [package ifneeded] script as well. An explicit call does however
>> have the advantage that one can, if necessary, customise the
>> initialisation (no, I don't have a clear use-case for that right now;
>> maybe too tired).

Having slept on the matter, I now have "configuration for nonstandard 
test environment" as use-case. The initialisation command put in the 
.test file would do a default init (e.g. assuming tcllib CVS 
organisation of files, using current file as reference), but extra 
commands given before sourcing the test file could specify overrides 
for the defaults.

For example, one might do:

package require tcllib::testutilities
tcllib::testutilities::declaredir modules/math \
   /Library/Tcl/tcllib-1.6/math
source foo.test

to specify an override that "whenever the test file wants to [use] 
something in modules/math, it should use the corresponding file in 
/Library/Tcl/tcllib-1.6/math". There's no harm in doing [package 
require tcllib::testutilities] twice, unlike the corresponding explicit 
[source].


>> What is gained by [package require tcllib::testutilities] is primarily
>> that one avoids hardcoding paths (relative paths, yes, but still
>> hardcoded paths) into the test files.
> 
> The price you are paying for this is that you now cannot run the testsuite
> anymore if Tcllib is not installed because the package won't be found. Or
> using the wrong helper package if some other version of Tcllib is installed.

That's a very pessimistic view of the matter. The only case I can think
of in which one would like to run the tcllib testsuite without having
/any/ version of tcllib installed is "make test"-style activities:
testing new software before actually installing it. In this situation,
the environment is fairly well controlled, so providing an extra
package is not a problem.

Developers working on tcllib should be expected to at least have some
version installed, so unless you foresee several radical changes in the
testutilities API, problems because the installed version is not that
of CVS HEAD should be rare, and easily recognised when they eventually
occur. What could be inconvenient is the transition period when such a
package is being introduced into tcllib, but OTOH it would probably
take a couple of years before any large portion of tests were rewritten
to take advantage of it. ;-)

> Running the testsuite of Tcllib without Tcllib installed is IMHO an
> important use case during development.

What is *lost* with the

source [file join \
	[file dirname [file dirname [file join [pwd] [info script]]]] \
	devtools testutilities.tcl]

arrangement is the ability to run tests /without having all of the
tcllib repository at hand/. Wherever I have a foo.test, it is assumed
that there is a ../devtools/testutilities.tcl to source. There will be
such a file if you've checked out all of tcllib or tcllib/modules from
CVS, but at least I find it much more prudent to check out only "my
own" module (especially if the project hierarchy in which it was
originally developed doesn't match tcllib).

> To re-enable execution you have to extend the auto_path, 

Which is quite feasible to do from the environment in the "make test"
scenario, and unnecessary otherwise.

> adding again the path information you do not want to the .test files.

Of course it shouldn't be the responsibility of the .test files to
provide this information! The main point of having the [package]
mechanism is to allow code to call upon other code without knowing
exactly where it is found!

> Even so it stays
> brittle because anybody can intercept this by adding a higher version of the
> helper package anywhere on the auto_path.

If that is brittle, then it is so only because the development of the
helper package is being mismanaged! A higher version of the package
will only be picked if it has the same major version number as the one
you require. The major version number must be incremented if the
package is changed so that it is not backwards compatible. So how could
newer versions be a problem?

Lars Hellström

Re: [Tcllib-devel] Writing tests - how?

[Andreas K. <and...@ac...>]

> Andreas Kupries skrev:
> >> Well, what about a small helper package? One could make the above
> >>
> >> package require tcllib::testutilities
> >> tcllib::testutilities::init
> >>
> >> or something like that. The separate [tcllib::testutilities::init] call
> >> would be needed to retrieve the [info script] data, although now that I
> >> think about it, one could (if really devious) embed such a call into
> >> the [package ifneeded] script as well. An explicit call does however
> >> have the advantage that one can, if necessary, customise the
> >> initialisation (no, I don't have a clear use-case for that right now;
> >> maybe too tired).

> Having slept on the matter, I now have "configuration for nonstandard
> test environment" as use-case. The initialisation command put in the
> .test file would do a default init (e.g. assuming tcllib CVS
> organisation of files, using current file as reference), but extra
> commands given before sourcing the test file could specify overrides
> for the defaults.


> For example, one might do:
>
> package require tcllib::testutilities
> tcllib::testutilities::declaredir modules/math \
>    /Library/Tcl/tcllib-1.6/math
> source foo.test

Ok, this is different from what I thought it was per your first email.
There it looked to me as if the

	package require tcllib::testutilities

statement was inside of foo.test, replacing the big source/file/info script
construction.
Now it has moved outside, to whatever is invoking the test script.

Is my understanding of both older and current/here setup right?


> to specify an override that "whenever the test file wants to [use]
> something in modules/math, it should use the corresponding file in
> /Library/Tcl/tcllib-1.6/math". There's no harm in doing [package
> require tcllib::testutilities] twice, unlike the corresponding explicit
> [source].

Uh. I am not sure if that sort of mapping is a useful feature. More thinking
required.

> >> What is gained by [package require tcllib::testutilities] is primarily
> >> that one avoids hardcoding paths (relative paths, yes, but still
> >> hardcoded paths) into the test files.
> >
> > The price you are paying for this is that you now cannot run
> the testsuite
> > anymore if Tcllib is not installed because the package won't be
> found. Or
> > using the wrong helper package if some other version of Tcllib
> is installed.
>
> That's a very pessimistic view of the matter. The only case I can think
> of in which one would like to run the tcllib testsuite without having
> /any/ version of tcllib installed is "make test"-style activities:
> testing new software before actually installing it.

Your view seems to be for a person/role getting the sources of Tcllib,
building, testing, then installing.
Not sure what name to give that role, it is not a 'developer' I would say.
Maybe 'installer'.

To me 'make test' is an integral part of 'development' activities. I.e.
testing the software while working on it, making sure that changes do not
break things. Like I did, for example, yesterday when speeding up the
struct::stack Tcl code a bit. Would be bad if it became fast, but also
wrong. Proactive testing before committing changes, instead of waiting for
installers to tell me what I broke.

> In this situation,
> the environment is fairly well controlled, so providing an extra
> package is not a problem.

Hm ...



> Developers working on tcllib should be expected to at least have some
> version installed,

It is likely. Do I want to depend on that? It makes for too much coupling to
the outside in my mind. I prefer that development is in a sandbox, something
self-contained, or, if not possible, minimal dependencies.

> so unless you foresee several radical changes in the
> testutilities API, problems because the installed version is not that
> of CVS HEAD should be rare, and easily recognised when they eventually
> occur. What could be inconvenient is the transition period when such a
> package is being introduced into tcllib, but OTOH it would probably
> take a couple of years before any large portion of tests were rewritten
> to take advantage of it. ;-)


> > Running the testsuite of Tcllib without Tcllib installed is IMHO an
> > important use case during development.
>
> What is *lost* with the
>

[stmt1]
> source [file join \
> 	[file dirname [file dirname [file join [pwd] [info script]]]] \
> 	devtools testutilities.tcl]
>
> arrangement is the ability to run tests /without having all of the
> tcllib repository at hand/.

I believe you meant 'source directory' instead of 'repository'.

I think I am beginning to understand our differences of view, which are
fundamental.

I am assuming and expecting that development on a part of Tcllib, i.e.
something like 'modules/report' always happens in a sandbox containing the
whole of the Tcllib sources. Together with my drive to avoid external
dependencies I arrive at [stmt1], which reflects both.

You seem to have the case where you copy 'modules/report' somewhere else,
being standalone, and still wish to be able to test it. At which point you
need the installed Tcllib, to find dependencies on other packages in Tcllib,
like struct::matrix.

Ok, that sounds quite artificial ...

A less-artificial case seems to be that: You develop a new package FOO, and
you start outside of Tcllib, do the testing outside, and then later wish to
drop it into Tcllib and have the tests working without change.

In that case I would have actually started developing FOO from within a
Tcllib sandbox, having the assumed envirnment available from the beginning.


My main conclusion here is that I see the non-ability to run tests without
having all of the tcllib source directory at hand as no loss at all.

In a way, we both need and assume the existence Tcllib, always, we simply
choose different locations where to find it.
You assume to have it installed, and I go and assume that I have all the
sources.

I like my approach because I believe it gives me better control about the
test environment and less possibility of interference, despite having to put
up with the longish command to load all that environment.


> Wherever I have a foo.test, it is assumed
> that there is a ../devtools/testutilities.tcl to source.

Yes.

> There will be
> such a file if you've checked out all of tcllib or tcllib/modules from
> CVS, but at least I find it much more prudent to check out only "my
> own" module (especially if the project hierarchy in which it was
> originally developed doesn't match tcllib).

Reading this now, after writing all of the above I feel stupid. It seems I
just paraphrased everything written now, and could have spared me the
effort. OTOH, seeing my inference of usecase matching your description now
makes me fairly sure that I have some understanding of your thoughts.

We seem to have fundamentally different views on the process and system.


> > To re-enable execution you have to extend the auto_path,
>
> Which is quite feasible to do from the environment in the "make test"
> scenario, and unnecessary otherwise.
>
> > adding again the path information you do not want to the .test files.
>
> Of course it shouldn't be the responsibility of the .test files to
> provide this information! The main point of having the [package]
> mechanism is to allow code to call upon other code without knowing
> exactly where it is found!

True. However with testing, where I want to rigorously control the
environment I consider exactly that a disadvantage.

> > Even so it stays
> > brittle because anybody can intercept this by adding a higher
> version of the
> > helper package anywhere on the auto_path.

> If that is brittle, then it is so only because the development of the
> helper package is being mismanaged!

> A higher version of the package
> will only be picked if it has the same major version number as the one
> you require. The major version number must be incremented if the
> package is changed so that it is not backwards compatible. So how could
> newer versions be a problem?

I agree, they shouldn't be. However, can you bet on that? It is easy to
mismanage this, have a bug


Thinking further, seems that my thoughts are churning (in a good way).

For one of the, right now half-baked, ideas which this discussion just
tossed up into my conscious mind is that our Tcllib 'testutilities' are in
some sense actually special, they are not a regular Tcllib package we
install. But they are, also, something, which is very common, similar to
'tcltest'. In a way they are an extension of 'tcltest' ... Can it be made
(or is) generic enough tthat we should/could install it ?

If it is generic enough we can move it ouf Tcllib. Then my feelings about it
as package required dependency seem to change and allow that, as it would
then be something managed externally anyway (i.e. like tcltest). The
question is, how much of the testutilities code is tied to the sepcialities
of Tcllib ... Oh, another flash of an idea ... With it outside, have it
overide the 'package unknown' command, search the code, like Tcllib for
packages first, and ignore packages of the same name outside ...

... I think I better stop here ... let it settle and think/sleep about it
more ...

Note: The testutils are a conglomeration of several groups of commands, each
group could be their own package ... Make a set of higher level test
framework packages ... Ok, I really have to settle and meditate ...

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [Tcllib-devel] Writing tests - how?

[KATO K. <k.k...@gm...>]

*** 'installers':

How to specify forcibly the module of testsuite used by the [whole
test] before installation can be considered. It is the form where
[tcltest-2.x.x.tm] is enclosed in the distribution package of tcllib.
(Probably it is arranged below at [support/devel/*])


*** 'developers':

Except for the minute version difference, we may assume that the
common testsuite tool is installed. I want you to be the form which
can do both the whole test of tcllib and the simple test of the module
I am writing.


Now, the test script is arranged to the same directory as each module,
and there may be assumption of operating a test script alone by a
modular current directory. That is, there is two usage.


(1) ensemble test
$ sak test run modules/foo

(2) single test
$ cd modules/foo
$ tclsh foo.test

In (2), it should be cautious of necessarily not using devtools of tcllib.
But it will be thought that he wants to use convenient support-tool.
However the tool is not necessarily installed at[.. /devtools/*]


*** 'solution':

Branch is required to support both (1) and (2).

# ---------------
# foo.test begin

if {[lsearch [namespace children] ::tcllibtest] == -1} {
    # (1) ensemble test
    package require tcllib::testutilities
    testsNeedTcl     8.3
    testsNeedTcltest 1.0
    testing {
        useLocal foo.tcl foo
    }
} else {
    # (2) single test
    set selfrun 1
    package require tcltest
    namespace import ::tcltest::*
    source foo.tcl
}

test foo-1.1 "concrete tests..." { [body] } { result }
test foo-1.2
...
..
.

if [info exists selfrun] {
    tcltest::cleanupTests
} else {
    testsuiteCleanup
}

# foo.test end
# ---------------

What is necessary is just to guarantee operating correctly by (1) as a
test script enclosed to tcllib.