Adding a test framework would require a way to include & track this dependency.
I see three possibilities
* Copy-and-forget: Add a copy the upstream testing framework and add it as-is
to the source code repo.
* Include-dependency-management: Add some kind of dependency management, e.g.
cmake packages.
cmake vs autoconf/automake is somehwat heated discussion. At the moment
the project is using autoconf/automake since it has always been using that.
* Use-the-SCM: Use git submodules to add the dependency.
I dislike Copy-and-forget because it pollutes the repository, and makes
tracking upstream changes very hard.
I have no experience with Makefile based dependency management
But I do know how to handle a git submodule.
I have a very strong preference to using a git submodule for unit testing.
I think how to put a testing framework into git is secondary. If unit
tests are useful in the current state, we can discuss about how to
include them.
Arne
I think the first step would be to identify the places where unit tests
could be implemented easily (if any), and where they would do most good.
If something falls to both of these categories then writing a unit test
there would probably make sense.
Then there's the other codebase (3.x) which, when publicly released,
might be a good/better candidate for writing unit tests.
If we end up writing unit tests, I too would prefer the Git submodule
approach.
--
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc
irc freenode net: mattock
