Post History

- "Black box testing" makes sense when dealing with opaque types so that's the first thing you should be doing and probably the most meaningful test too, so that's where you should put most of your efforts. But that's not what you are asking about here.

- Some philosophies like TDD would encourage you to write the test along with the code and include it in the source from scratch. The advantage is that you'll be writing the test while you are writing the code, allowing you to spot bugs early on and letting you write the test while everything is still fresh.

  The disadvantage is that it's bad practice to keep source around which isn't executed in the production build. That practice is banned in mission-critical software. Similarly, using `#ifdef` switches is also bad practice since it makes the code harder to read and maintain.

- Testing the internals could otherwise be done by creating a test branch and modifying the code there to include the tests. It's kind of similar to including the .c file or moving the struct definition to a header during the test, all are just different flavours of the same thing. Either way the original file is untouched, though you need to ensure that your test code doesn't have any impact on it. Exposing the internals could lead to namespace collisions etc.

- There's no need to overthink testing and be hellbent on automated testing with output through stdout etc. You can just write a manual test such as:

  >  arena.c, test n.n
  >  
  > Purpose: Ensure that `arena_reset` clears all the memory pool.  
  > Method: Launch the program in debugger x with build settings y. Set a breakpoint at the end of arena_reset. Watch `arena->pools`, all `offset` members must be set to zero. Watch `arena->current`, verify that it is 1.

  This is perfectly fine, just document the test in a protocol. When the test was done, for what build and what was the outcome. If someone thinks this is more cumbersome and takes more time than automated tests, they are fooling themselves. 

- If you know the size of the struct you could just dump _n_ bytes of the memory starting from the opaque pointer and reverse engineer it from there. Cumbersome but might expose security issues because this is something that the user of your code could as well be doing too.