I have a binary test for the new libbu function bu_gmtime and I'm trying to
figure where it should go.
In the Testing section of HACKING it says:
... Also added are the dependencies of the tests on
binary executable rtweight and test_vls, respectively....
The binary 'test_vls' no longer exists so that needs correcting, but its
missing example begs the question of where/how in the source tree to fit
the new test binary (the main function does the test and returns 0 for
success and 1 for failure)?
I assume it will be driven by a shell script in ./regress, but where should
the binary (and its source file) be put?
On Tue, Aug 27, 2013 at 4:41 PM, Tom Browder <tom.browder@...> wrote:
> I have a binary test for the new libbu function bu_gmtime and I'm trying
> to figure where it should go.
Ah, I just found the 'test' target. Is it in 'testing' or is it planned to
be part of the release process (i.e., additive to the 'regress' target)?
On Aug 27, 2013, at 5:41 PM, Tom Browder wrote:
> I have a binary test for the new libbu function bu_gmtime and I'm trying to figure where it should go.
Awesome. They go into the src/libbu/tests directory. Run "make test" to invoke.
> In the Testing section of HACKING it says:
Updated and expanded.
> I assume it will be driven by a shell script in ./regress, but where should the binary (and its source file) be put?
The regress/ scripts drive integration regression tests, basically testing user application-level behavior for expected results. Run "make regress" to invoke. These are usually added after a particular problem is encountered more than once in a given tool (e.g., 'red' command woes, fastgen conversion, etc).
Unit tests are for testing API functions or other code, not implemented as scripts, and are simple C/C++ programs. They should call as few functions and have as few dependencies as possible. They should isolate the code being tested as much as is needed to test a given function. They are in tests/ subdirectories (in each library) and all invoked with the "make test" target.