Re: tcltest Tk Applications
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


comp.lang.tcl archive

Re: tcltest Tk Applications

From: Erik Leunissen <look@the.footer.invalid>
Date: Mon May 30 2005 - 15:10:19 CEST

Erik Leunissen wrote:

> I just found a fix for the problem that I addressed in the previous
> posting. See the code inside "setupScript" in the test script below.
>

But all access to files other than stdout, stderr and stdin will remain
a very big

                      PITA

The following example test "writeToFile" will cause an error because the
call to puts in [writeToFile] requires the channel $fd to exist. While
that is the case in a normal execution environment, it is not in a slave
interpreter unless you make it explicitly available using [interp
transfer]. Since the [puts] immediately follows the opening of the file,
there is no way to do that in a timely fashion when you're writing the
test script. You could of course insert it into the proc to take into
account that in the future it may be executed in a test environment that
uses slave interpreters, but ... good heavens, NO.

Are there any people who see a workable solution here?

Or should we conclude that the best thing is not to use slave
interpreters when the code that you want to test accesses files other
than the standard ones?

set proc writeToFile {txt} {
     set fd [open ./testFile w]
     puts $fd $txt
     close $fd
}

set setupScript {
     interp create slave
     slave alias puts puts
}
set cleanupScript {
     interp delete slave
}

test writeToFile {exercises a file access error} \
     -setup $setupScript -body {
        slave eval writeToFile tralala
} -result "" -returnCodes ok -cleanup $cleanupScript

-- 
   leunissen@       nl | Merge the left part of these two lines into one,
e.          hccnet.   | respecting a character's position in a line.
Received on Thu Sep 29 14:19:39 2005