On 21/04/16 20:01, Gert Doering wrote: > Hi, > > On Thu, Apr 21, 2016 at 07:40:16PM +0200, Jens Neuhalfen wrote: >> The first candidate would be the U2F integration that I???d like >> to write. A proven strategy for starting unit testing is to write >> tests for all new features. This way the up-front cost is reduced >> to the invest for ???the first test???. > > A test driver for the plugin API is actually something which might > work reasonably well as test rig... >
I have started working on a patch set to make it possible to unit test plug-ins more easily. But for this to make sense, I need to clean up the OpenVPN code somewhat so it is possible to base it on much of the code base already existing in OpenVPN. That's a good way to also test the OpenVPN side of the plug-in API. Now all that sounds easy enough. Then I realised a massive code clean-up is needed, as there are some cross-dependencies where the plug-in unit test framework would suddenly need the full network stack in OpenVPN (which plug-in code paths never cross - yes socket.c, route.c and forward.c was needed in my first attempts). I did come quite a good step forward on the last hackathon ... unfortunately my work+family situation have made it hard to hack further on that in a long while. But I have good hopes to believe I'll be able to spend more time on this in not very far future. The reason for looking into a test framework for plug-ins is that we have some auth-pam patches we've been very cautious with due to lack of testability. And many more plug-ins can benefit from such a test framework too. > OTOH, testing one-time-passwords in an automated manner sounds > complicated. Not really, there are pretty solid TOTP/HOTP libraries which can be integrated into test frameworks without too much hassle. You just need some keying material to be consistent between server side and client side of the test. I've already poked into this a few times. -- kind regards, David Sommerseth
signature.asc
Description: OpenPGP digital signature
