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

[Thomas Friedrichsmeier]

Hi,

On Thursday 07 October 2010, meik michalke wrote:
> i didn't install the roxygen package system wide, but to $HOME/R, amongst a
> lot of other packages. i don't want to mess with system directories handled
> by dpkg, so anything i fetch directly from a CRAN repository stays in my
> $HOME. usually this works great, but "R CMD roxygen" seems to care only
> about $RHOME and ignore $R_LIB and $R_LIB_USER :-/

yes, that occurred to me a while later. Perhaps something like
  R CMD /your/full/path/to/roxygen
will work, though? Provided that the roxygen script got installed somewhere.

> yes, otherwise this would only give meaningless warnings: the objects that
> rm() tries to remove from globalenv have never appeared there, because they
> are now only created temporarily inside the functions' environemental
> context.

I see. Not quite, though: They are assigned into the rkward-environment (note 
the "<<-" assignment).

Assigning them only locally would not work as expected in the testing 
framework, since the plugin-code is always evaluated in globalenv(), not in 
the environment where rk.call.plugin() was called.

You might consider assigning explicitly to globalenv() (as is done with 
"date()"), and then allowing to remove them with rktest.resetEnvironment, as 
before. The idea was to provide a convenient way to restore a mostly normal 
environment while developing the tests. Of course then 
rktest.resetEnvironment() should also be exported.

> i forgot to mention that i removed the function calls at the end of all
> test suites (it's part of the main function), so currently the old testing
> framework is broken. is that ok?

I already changed all_tests.R accordingly, so
  make plugintests
works again.

> for a plugin test now one only has to provide a valid suite object,
> everything else is handled by rktest.makeplugintests(). if your testing
> the package doesn't show probelms, we could replace the old framework
> completely.

Yes. I do see a few test failures, which I don't understand, yet (but these 
might also be related to something entirely different).

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/20101007/42a8aa85/attachment.sig>