Test infrastructure for internal algorithms

[jpola]

This issue emerged with #135. @shuaiche and me have to develop several internal algorithms. Since new algorithms will be more complex it will be very useful to develop a test infrastructure which helps to easily validate and debug internal clSPARSE algorithms. Nowadays I did that by adding temporary interface API functions in clSPARSE.h but that is very time consuming and it is limited with C language restrictions.

Do you have any ideas how to tackle this issue? Where to put new test-internal folder? How the project tree should look like?

What is your experience with that?

[kknox]

Give me a day or two to brainstorm 🔮

[kknox]

The complicated part of testing internal routines, is that we normally compile our library as a dynamic shared module, and it does not export routines unless they are decorated with CLSPARSE_EXPORT.

That leaves two options available on the table:

• We write internal test programs that MUST link to the library as a STATIC module, or the linker will complain of unresolved symbols
• We write internal test programs that compile in bits of the library we want to internally test, i.e. it includes as part of the test executable files from the library. In this way, the test program avoids linking in the library altogether.

[jpola]

Hi, what I would like to have is to take part of the clSPARSE (internal
data structures, kernel mechanism execution and probably other existing
algorithms and put it nicely into one "internal" test which helps to
develop other algorithms. Here I want to avoid linking with the clSPARSE
library, it can be broken in some places during the development. Is that
idea is described in second point of your script (Forgive me I didn't
understand what you have written there)?

2015-09-08 7:42 GMT+02:00 Kent Knox notifications@github.com:

The complicated part of testing internal routines, is that we normally
compile our library as a dynamic shared module, and it does not export
routines unless they are decorated with CLSPARSE_EXPORT.

That leaves two options available on the table:

• We write internal test programs that MUST link to the library as a
  STATIC module, or the linker will complain of unresolved symbols
• We write internal test programs that compile in bits of the library
  we want to internally test, i.e. it includes as part of the test executable
  files from the library. In this way, the test program avoids linking in the
  library altogether.

—
Reply to this email directly or view it on GitHub
#137 (comment)
.

[kknox]

Yes, so I think either of the two options I listed above would work, and I am leaving it open to see which way you would prefer. To explain in more detail:

• Our test programs that provide unit tests through the public clSPARSE API would remain as is and link to our library dynamically. If you create an 'internal' test executable, I imagine that you would provide API's that you want to 'test' in our internally global clSPARSE-private.h, or some other internal header file that you could #include in your test program directly. To do this, we would have to modify the cmake build to also create static clsparse libraries, to get access to the internal symbols. You then compile your internal test executable and link in the static library, and all symbols should resolve. This has hte benefit in that the library object code is still digested in a 'library' format; only the header files would be explicitly part of the test executable. This is probably the easiest solution, but needs significant build support
• Alternatively, you create a test executable that #includes library header files and builds individual library files as part of the test project. I think this one is self explanatory, and would require almost no build modifications, but is slightly more fragile. If developers in the future shuffle files around or rename them, they will easily break the test executables too.