What we have for tests are system tests, i.e. tests that exercise the system functions. In doing so we (hope to) test all the code underneath. These tests all involve the external functions from netcdf.h.
One thing Russ and I discussed back in olden times was to also add some unit tests. That is, tests of netCDF internal functions. Back in olden times there were fewer internal functions, and we never got around to adding testing just for them. But now there are more internal functions, as the capabilities of the dispatch layer and libsrc4 have grown.
At the moment I would like to write tests for the code in nclistmgr.c and I don't really have a good place to put those tests.
So I suggest I add a unit_test directory. It will come first in the test order, and will contain unit tests for the code in libdispatch and elsewhere which is always built (i.e. for both classic and netcdf-4 builds.) I would then later add an unit_test4 for unit tests of code in libsrc4 that is only built in netcdf-4 builds.
There is a good reason to keep system tests and unit tests separate. By monitoring the code coverage of system tests, we can find code that is not really used. However, unit tests obscure this, since they test the internal functions. So those functions always show up as tested code, even if they are never actually used anywhere in the code base. I will add a configure option to disable unit tests, so I can measure code coverage properly.
@WardF and @DennisHeimbigner does this seem OK?
What we have for tests are system tests, i.e. tests that exercise the system functions. In doing so we (hope to) test all the code underneath. These tests all involve the external functions from netcdf.h.
One thing Russ and I discussed back in olden times was to also add some unit tests. That is, tests of netCDF internal functions. Back in olden times there were fewer internal functions, and we never got around to adding testing just for them. But now there are more internal functions, as the capabilities of the dispatch layer and libsrc4 have grown.
At the moment I would like to write tests for the code in nclistmgr.c and I don't really have a good place to put those tests.
So I suggest I add a unit_test directory. It will come first in the test order, and will contain unit tests for the code in libdispatch and elsewhere which is always built (i.e. for both classic and netcdf-4 builds.) I would then later add an unit_test4 for unit tests of code in libsrc4 that is only built in netcdf-4 builds.
There is a good reason to keep system tests and unit tests separate. By monitoring the code coverage of system tests, we can find code that is not really used. However, unit tests obscure this, since they test the internal functions. So those functions always show up as tested code, even if they are never actually used anywhere in the code base. I will add a configure option to disable unit tests, so I can measure code coverage properly.
@WardF and @DennisHeimbigner does this seem OK?