2

Before trying to do any unit testing, I had a directory like

mything.h
mything.cpp
mything2.h
mything2.cpp
driver.cpp  // contains main()
Makefile

Then I would make and run the produced executable; this executable was produced in the root directory (call it runme).

Now I'm trying to use Catch2 https://github.com/catchorg/Catch2/blob/master/docs/Readme.md#top) which also says to have one testing file with a main (they have a define for it). So I reorganized my code as

src/
  mything.h
  mything.cpp
  mything2.h
  mything2.cpp
  driver.cpp  // contains main()
test/
  catch2.hpp // downloaded off their website in single header option
  sometest.cpp // also contains a main per catch2
Makefile

I made some dummy tests that don't reference my actual code. Now I do make tester and ./tester which runs all the tests. And I can do make and ./runme to run my original application.

My question now is, how do I actually call my source code from the test code? Do I need to convert this src dir into a library? That is, how test code references src code in c++ is a bit unclear to me.

For full disclosure, I'm coming from the python/pytest world, and wondering how you actually structure c++ code w.r.t. unit testing or proper project structure.

Tommy
  • 12,588
  • 14
  • 59
  • 110
  • What are you trying to test? You can compile your components into libraries and link to those in your test, but that doesn't test your app. For that, you need to invoke your application from the test code. If you arrange your `main` function to simply call into your mything library at a single entry point, then you can do 90+% of your testing through the library interfaces. – jwdonahue Oct 02 '18 at 19:52
  • I was trying to test functions in `mything`, not the end executable. Like, unit testing some functions in my original code. It seems I have two options: compile everything together as one happy family (meaning, include the original headers in the test code so everything gets compiled together), or take the `.so` route, generate an `so` from the original code, and reference the `.so` from the test code. I don't know what is proper though. Or what is common, or typical, etc. The so route seems nice in that changes to the tests don't require a recompile of everything? – Tommy Oct 02 '18 at 20:01
  • You can compile your mything code directly into your test executable. Just add the source files to your makefile for test. What does your makefile look like? – jwdonahue Oct 02 '18 at 20:04
  • The make for the code is more complicated: it involves cuda libraries and a different compiler (nvcc) linking with a g++ compilation. The test code is very simple. This suggestion is my first option in the comment above; just compile everything into the test. This makes my compilation of the test more complicated, but I guess this path is easier than making an SO. – Tommy Oct 02 '18 at 21:18
  • Best practice is to create libraries and link those into the different executables. Compile once, reuse many times. But if you don't ever have to scale up to a CI build system, just compile the code twice, once for the test and once for the app. – jwdonahue Oct 02 '18 at 21:22

0 Answers0