> 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 simply write bindings to convert R's SEXP objects into something consumable by your library (usually this is just whatever the SEXP points at). Using git submodules is a nice way to keep your library separate from the R interface. here's an example for you. tslib, which has it's own c++ test suite (using boost.test): http://github.com/armstrtw/tslib/blob/5b0fe2fc5ecb393d1dca097c2c19008227eb6c7e/test/test.cpp and fts which simply implements wrappers to call tslib:http://github.com/armstrtw/fts/blob/2b6cb4045f852211b9334b43730409a13dd353c0/src/interface.cpp Also, check out Dirk's Rcpp package, which should make your life easier if you use c++, and check out my RAbstraction package which tries to do what Rcpp does using templates. http://cran.r-project.org/web/packages/Rcpp/index.html http://github.com/armstrtw/rabstraction/tree/master -Whit ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel