On Fri, Aug 22, 2014 at 3:48 PM, Franck Joncourt <fra...@debian.org> wrote:
> Hi Michael,
>
>
Hi Franck,
> [...]
> > > I have not checked the full lcov report yet to find out which functions
> > > would
> > > take benefit from unit testing. We can easily write many tests, but it
> can
> > > become quite time consuming. I think, first we can try to add this
> > > framework
> > > and see how to integrate it easily in the development process and take
> > > care to
> > > increase fwknop code coverage.
> > >
> > > I will be glad to have a look at it this week if you do not mind.
> >
> > Sure that would be great. Perhaps c unit tests should be gated by a
> > ./configure command line switch and corresponding #if blocks (like the
> > --enable-libfiu-support switch)?
>
> I was wondering if the unit tests should be added to each file
> * config_init.c
> * get_password.c...
>
> to be able to reach static functions inside them, or if they should be
> defined
> in other files:
> * test_config_init.c
> * test_get_password.c
>
> I think for both methods, a test module (a collection of unit tests) should
> create its own test suite and register it to the main test module. Then the
> main test module will run them and display results or return an error code
> in
> case a failure occurs.
>
> Right now I have tried something like that:
>
> fwknop_utest project
> |--> test_config_init.c/.h --> config_init test suite
> |--> test_get_password.c/.h --> get_password test suite
>
> but, at a first glance, it not easy to test since I have only access to
> general
> functions such as config_init() in config_init.c
>
> Either tests should be embedded directly in fwknop files (config_init.c for
> example) or:
> * some static/private functions might become available as public
> functions
> if needed
> * some public functions might be refactored if needed
>
> I have not checked further fwknop base code yet. What do you think?
>
>
My sense is that it would be better to have the tests built into each file
directly, but wrapped with '#if HAVE_C_UNIT_TESTS' along with a
corresponding './configure --enable-c-unit-tests' argument [1]. This would
be similar to how the libfiu fault injection stuff was done for 2.6.3, and
it helps to ensure that production releases of fwknop do not contain any of
the C unit testing code. Also, this would address the static vs. public
issue I believe - it would be good to keep functions static to ensure
compartmentalization of code that shouldn't be seen outside of file scope.
Do you think this would work? Perhaps when you are ready, you could create
a c_unit_testing branch on github with an example of this for, say,
client/get_password.c, client/config_init.c, or one of the lib/*.c files?
That way I can fetch your branch and try to follow along?
Thanks,
--Mike
[1]
https://github.com/mrash/fwknop/commit/02389932bc23db025b13a07665858ed50fe48b6a
and
https://github.com/mrash/fwknop/commit/35ad8323928ebdf07fad38bed22e65f099dfae02
> Regards,
>
> --
> Franck Joncourt
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Fwknop-discuss mailing list
> Fwknop-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
>
>
--
Michael Rash | Founder
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Fwknop-discuss mailing list
Fwknop-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
