I am currently developing an R package where most of the computational work is done in C code. In particular, I have several complex C routines for which I then wrap with an R function. These I know I can test using testthat because the namespace includes the C function called (I am using roxygen comments to generate the namespace).
The difficulty I am having is that some of these C routines have a few complicated subroutines, the output of which is non-trivial to check. These functions are never called from R directly, so there is no code in my R/ directory that has a roxygen comment that results in the namespace making these functions available. What I want to do is write an R routine that performs the same computation and then use testthat to compare against the output of the C function. I have done this and it works great when I load the entire shared library (using dyn.load), but I don't think this is the proper approach for tests in a package that I intend to submit to CRAN.
My current workaround is to create a dummy function in a file in my R/ directory that then has a roxygen comment for each of the functions I wish to load. That way when I run devtools::document(), these functions are included in the namespace.
Is this the best approach, or is there another method that is better/preferred?
Related
I recently got into Unit-Testing embedded C Code.
I'd like to test each module fully isolated from all the others. This approach requires me to simulate (or "fake")
all the dependencies and external calls a module makes.
Doing just that, I would end up with multiple definitions for the same function -- all the fakes would have the same identifier.
I believe the most common approach to avoid having multiple definitions is to compile one binary
for each test -- instead of one big program for all tests.
However this introduces new difficulties. I need a main()-Function for every Module under Test. Also each program now prints its own summary instead of one the total
test summary. Oh and its quite tedious to set up the build environment to do this...
There is very likely a smart way to do this. How is it done correctly?
I am trying to implement TDD in C coding. I am building the program structure in a quite modularised way and using as atomic functions as possible. I make one test file (including several suits) for one module (module = header file + source file). I am struggling to make the program files "not know that they are being tested", in other words - I don't want testing parts of code in the proper program. Therefore almost often I need to include the source file in the test file in order to have access to the "private" variables and functions.
That was the intro, now the problem: if in a module I have an aaa() function, which uses inside a bbb() function, which uses some xxx() function from an external module, I can easily test the bbb() function in the atomic way by mocking the x() function: #define bbb mock_bbb and providing a mock xxx module for #include. However, I am unable to find a way of atomic testing of the aaa() function, which uses a function from the same module. Is it possible to do? (note, that apart of mocking bbb() for aaa(), I have to be also able to use the original bbb() to test it)
My closest try was to use -Wl,-wrap,xxx, but the problem is that I haven't found a way to automate this (wildcard or something?) - I will have almost 100 testing files, each containing several functions to test - I cannot allow myself to put manually every function in the makefile.
I never test "private" functions in an atomic way. I usually unit-test a c-module using its public functions and checking its calls to other modules (using mocks through dependency injection) and checking its private data members (by exposing its private data members with a GetDataPtr()-function that is compiled only for the unit test project).
For me that the best tradeof between effort and complexity of the unit test framework, although it not possible to reach 100% statement coverage in some "private" functions.
I have a devilish-gui.exe, a devilish.dll and a devilish.h from a C codebase that has been lost.
devilish-gui is still used from the customer and it uses devilish.dll
devilish.h is poorly documented in a 30-pages pdf: it exposes a few C functions that behave in very different ways according to the values in the structs provided as arguments.
Now, I have to use devilish.dll to write a new devilish-webservice. No, I can't rewrite it.
The documentation is almost useless, but since I have devilish-gui.exe I'd like to write a different implementation of the devilish.h so that it log function's call and arguments in a file, and than calls the original dll function. Something similar to what ltrace does on linux, but specialized for this weird library.
How can I write such "intercepting" dll on windows and inject it between devilish.dll and devilish-gui.exe?
A couple of possibilities:
Use Detours.
If you put your implementation of devilish.dll in the same directory as devilish-gui.exe, and move the real implementation of devilish.dll into a subdirectory, Windows will load your implementation instead of the real one. Your implementation can then forward to the real one. I'm assuming that devilish-gui isn't hardened against search path attacks.
Another approach would be to use IntelliTrace to collect a trace log of all the calls into devilish.dll.
I am organizing some R code I have written into a package. This code contains MCMC algorithms for inference on parameters in ordinary differential equation models, so I will be solving the ODE thousands of times. Thus it is necessary to pass the model into the ode function of the deSolve package using compiled code instead of an R function. Normally, I use the commands
system('R CMD SHLIB mymodel.c')
dyn.load(mymodel)
to use the compiled versions. Instead, I would like R to automatically generate the .so files when I install the package. I cannot find a way to do this because these C functions are not for use as an R function. I just need the path to the valid DLL to pass into the ode function. It doesn't seem to make sense to make a wrapper for the ODE model since I can't use the function inside of R, but maybe I am confused. I cannot find a package on CRAN that uses C code in this manner, so maybe it is not possible.
I have an R function which is essentially acting as a wrapper to a set of C functions - the R code calls the C code through .C("..."). This C code could be parallelized and compiled using some MPI implementation. However, having never used MPI before, I have no idea if such MPI-ed code would even be callable from R in a way that would let MPI work?
Does anyone have any experience with this kind of thing? I'm guessing the R MPI libraries are pointless for my purpose, given all the work is done deep within the C code. This would ultimate be run on HPC cluster, if that makes any difference?
Can you use mpicc to create a shared objected, and if such a shared object was called from R would a parallel implementation run, or would you just get the serial version (or indeed, as I suspect, would it just crash)?
I may well be missing info needed to understand the problem, so will update accordingly.
You seem confused.
You could just use the existing Rmpi package to spawn parallel execution of several R instances (on your different nodes) and each of those can use your .C()-called code as well.
Maybe you want to work through some simple examples to get a better feel about what can or cannot be done?