> I couldn't find in the Testing & Validation docs any hint on how to 
> achieve the desired behavior. I guess test source code files should 
> go into a dedicated module in wscript, anyway not in the same module
> as regular code (which seems to be the current status).

There is no hint on how to achieve the desired behavior since I don't believe there's a reasonable way to achieve the desired behavior.

What is desired is that BVTs live with the code they check and go into libns3.  Unit tests should be collected into a unit test module; system tests should be collected into a system test module, etc.

I don't believe there is a way to collect unit tests from different directories into a single module in the current build system.  Historically, we have never done this, but have always built one giant library with everything in it.

So, this is really a build system issue, I believe; so I am renaming this issue and changing the component

My opinion is that testing code should not go into libns3.  I proposed to put it into test programs, one test program per ns-3 module.  It would then be the job of test.py to find the test programs and invoke them in sequence until all testing is done.

(In reply to comment #2)
> My opinion is that testing code should not go into libns3.  I proposed to put
> it into test programs, one test program per ns-3 module.  It would then be the
> job of test.py to find the test programs and invoke them in sequence until all
> testing is done.

I reassigned this to Mitch, who is working on this as part of the ns-3 modularity project.

I think you are suggesting also to remove utils/test-runner in favor of all of these per-module test executables.  How about naming them "modulename-test-runner.cc"?

The test hierarchy was supposed to be Build Verification Tests (BVTs) that were tiny little tests just designed to make sure that the system built correctly and that the base had all of the expected pieces, and they continue to work together as expected.  I had trouble considering building *any* tests into ns-3 proper, but this seemed like a possibly useful concept.  The idea that was that these tests could reside in the same source file(s) and be linked into ns-3.  It used to be the case that this was the only kind of unit-like test we had.

Unit tests are supposed to be the low-level very extensive tests.  This is the stuff that really needs to be moved out of libns3.  As I said earlier, some of the test object files are larger than the ns-3 code.  I thought that the unit tests for ns-3 could be collected into a unit test module; unit tests for other modules would be collected into similar modules.  I had hoped that system tests would work the same way.

The idea was that eventually these would be hooked into a test framework (perhaps as a shared library with a pre-defined entry-point) so consistent error reporting could be performed, rather than just executing a bunch of programs that each do whatever they wanted.  The test-runner is a first approximation fo this.

I had expected the per-module tests to be more like module-test.so and could be compiled from an arbitrary number of module-test.cc file that live in a module directory along with any per-module data (trace) files.

The idea was to have a unified test framework that could produce ns-3 test status HTML to be eventually linked from the ns-3 web site.  This was working for a while but buildbots stopped running for a long time and they were driving the process.  The big problem with the current approach is that everything has to be linked into ns-3, which is horrifying (and embarrassing).

By the way, the original comment:

>"There is really no reason for this kind of test to be built into an ns-3
>module."
> "Unit tests [...] are not built into the ns-3 code"

is a cut and paste error.  It should read,

"Unit tests [...] are not built from the ns-3 source code, but live in the same directory as the code they test"

This was resolved with the new modular build system.