On Fri, 2009-06-26 at 16:17 -0400, Whit Armstrong wrote: > > But this draws me back to the basic question. I don't want to run R > > CMD INSTALL 20 times per hour. How do developers "actually" test > > their code? > > check out RUnit for tests. > http://cran.r-project.org/web/packages/RUnit/index.html > > as for testing c++ code. I have taken an approach which is probably > different than most. I try to build my package as a c++ library that > can be used independent of R. Then you can test your library with > whatever c++ test suite that you prefer. Once you are happy, then I also have C++ tests that operate separately from R, though I have a very small library of stub R functions to get the thing to build. There have been some tricky issues with R (if one links to the regular R library) and the test framework fighting over who was "main." I think that's why I switched to the stub.
Working only with R level tests alone does not permit the kind of lower level testing that you can get by running your own unit tests. I use the boost unit test framework. Of course, you want R level tests too. Some of my upper level C++ tests are mirror images of R tests; this can help identify if a problem lies at the interface. For C++ tests I build my code in conjunction with a main program. I think I also have or had a test building it as a library, but I don't use that much. For R, my modules get built into a library. It's usually cleaner to build the R library from a fresh version of the sources; otherwise scraps of my other builds tend to end up in the R package. Thanks, Whit, for the pointers to Rcpp and RAbstraction. Ross Boylan ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
