[rkward-devel] rkwardtests package: done :-)

[Thomas Friedrichsmeier]

Hi,

On Wednesday 13 October 2010, meik michalke wrote:
> perhaps we could somehow move all file creation to a temporary directory.
> the only problem would be to keep it long enough for stuff like setting
> test standards, i guess.
> 
> let's say, we're using an object in globalenv() called ".rktest.temp.dir"
> to store the path name, and if this object doesn't exist (or
> "cleanup=TRUE"), a new tempdir and according object will be created. you
> could then use the same tempdir as long as needed. something like that.
> that way, you wouldn't have to unlink anything in potentially uncertain
> environemnts.

indeed, using a temporary directory could be a clean solution. I guess in this 
case a single directory might even be enough. We'd follow the same procedure 
of cleaning _before_ running the tests, not after, so the directory would 
always have the newest results or nothing.

It would still be safe, as long as the directory name is unique enough to 
avoid any likely collisions (and besides, data in /tmp/... can never be 
assumed to be 100% safe). And also, it would keep the test directory itself 
clean, which is a nice plus.

Of course this would mean adjusting the testing framework, and probably also a 
few tests. Would you like to continue on this?

> good :-) i'll work on some helper function to test external plugins next.
> i'll assume the contents of a (set of) plugin(s) looks something like
> this:

For the tests-directory, I suggest to mirror the "main" tests directory:

   tests/
      testsuite.R
      sometestsuitename/
         RKTestStandards.sometest.rkcommands.R
         RKTestStandards.sometest.rkout

True, most plugin packs will not have any need for more than one testsuite. 
But why not leave in the support? Probably, for the implementation, using the 
same layout, here, is a bit less complex, too.

> where the file/dir structure below plugins/ could be anything that matches
> the included .pluginmap and anything except .pluginmap, plugins/ and the
> plugin files is optional. agreed?

I'd say, even "plugins/" you not need to be strictly enforced (although 
encouraged), and note that supporting more than one .pluginmap does not make 
the implementation any more complex (for the little that we have so far, it 
should even work out of the box, already). So I'd allow a bit of wiggle room 
and put it as "at least one .pluginmap file", and plugins "should" go into a 
subdirectory "plugins".

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20101013/07c73104/attachment.sig>