To update this thread, the locked environment issue with S4 has been resolved by moving tests from test.data.table() into pkg/tests/tests.R. test.data.table() still exists and is callable by users, and the tests are easily viewable by users.
This resolves S4-ization and is in v1.5.4 on R-Forge. Thanks to Steve. We may yet move to test_that in future. Matthew On Wed, 2011-02-23 at 00:13 -0500, Steve Lianoglou wrote: > Hi Matthew: > > On Tue, Feb 22, 2011 at 7:32 PM, Matthew Dowle <[email protected]> wrote: > > Steve, > > > > We definitely need to include your S4 work asap. > > > > My thoughts on the testing are as follows (very likely due to my lack of > > knowledge) : > > > > 1) is test_that the best choice - what about Runit and SVunit? Which is > > the most acceptable/recommended by r-core? What do other packages use? I > > simply don't know - I've been meaning to investigate. Is there any > > document that weighs up the pros and cons of each? On what basis should > > we choose? R itself doesn't use any of these packages - how do they > > manage? > > I suggested test_that because (i) someone (maybe you?) said that a > previous patch was added for RUnit support, but it wasn't clear how to > run tests, so that patch was dropped. test_that allows easy ways to > run tests via R CMD check, but also you can easily test directories > etc. interactively from the R prompt; and (ii) it seems more > intuitive/user friendly to me and is still quite comprehensive with > respect to the types of tests you can check against, eg. normal tests > for equality/identity/inheritance, but also checks for calls that > should throw errors, warnings, or messages. > > If anyone strongly favors another testing framework, that's fine too. > > > 2) If the call to test.data.table() was moved out of .Rd and into tests > > directory, would the S4 tests then work? If yes, then the choice of > > testing framework may be distinct from the incompatibility problem. > > Perhaps. > > There was some locked environment issue that was messing things up. > > > 3) The tests in the v1.5.3 ?data.table manual page were revised > > recently. They are for users to look at; to learn data.table quickly. At > > least that's what I aimed for. They should be a subset of formal tests > > definitely, but did you really mean to move them out of .Rd ? > > I see. Maybe not(?). I think keeping a subset of the usage scenarios > in the Examples section is definitely useful, but last I checked, all > of the tests were in there (sorry if that's not the case -- I'll > double check when I get back to school tomorrow). > > I certainly wouldn't propose removing all scenarios/tests from the > example section, though. > > > 4) I've used specific numbers to various tests in various places at > > various times: FAQ, FR list, public posts and private emails. If we drop > > the test numbers how will we (I) identify them? There are specific > > numbers I know in my mind which often come up when I change anything - > > test 147 for example. I made a change recently so that test numbers can > > be float, and also independent of the counter of tests passed/failed. > > For what it's worth, the numbers/id's could be added to the tests > using the info/label arguments in test_that's expect_* functions. > > -steve > > > > > Matthew > > > > > > On Tue, 2011-02-22 at 14:06 -0500, Steve Lianoglou wrote: > >> Hi, > >> > >> Prompted by the earlier post today from Peter, I'd like to submit my > >> (simple) S4 patch back into the svn trunk. > >> > >> This has been on pause for me since we ran into the problem of > >> shoehorning the s4 tests into the current testing methodology, which > >> lead me to suggest using testthat for testing ... which I started to > >> do. > >> > >> We then spoke about whether or not push all of the tests into > >> testthat, or just do the s4 for now, and tests in future would use > >> testthat, and the current ones would stay where they are. > >> > >> Personally, I'm in favor of (gradually) moving all of the current > >> tests into testthat -- I've actually submitted patch to Hadley for > >> testthat that makes it easier to use the less verbose expect_* > >> shortform functions with labels so they are more informative. For > >> example, instead of: > >> > >> expect_that(1, equals(2), info="Testing numeric equality") > >> > >> one would do: > >> > >> expect_equal(1, 2, info="testing numeric equality") > >> > >> [The current version of testthat doesn't allow to add info/label args > >> to these short forms -- this is what I submitted a patch for). > >> > >> So, does this plan seem OK to the devs? > >> > >> (1) Add my S4 patch to datatable-trunk asap with unit tests using the > >> current version of test_that. > >> > >> (2) Once my patch gets into test_that, then I'd volunteer to > >> (gradually) migrate older tests into this framework (and out of the > >> data.table manual page). > >> > >> If we don't want to move the older tests into the test_that framework, > >> then we can just drop (2). > >> > >> Thoughts? > >> > >> Doing this sooner rather than later would be helpful for me so that I > >> can more easily track latest svn and all of the goodness that has been > >> added post 1.5.2, but I'm trying not to be selfish ;-) > >> > >> -steve > >> > > > > > > > > > _______________________________________________ datatable-help mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
