States of tests

[Amar Takhar]

On 2015-11-25 19:03 +0000, Mark Atwood wrote:
> 
> Ok.  Why were they commented out?  Did we comment them out, or were they
> commented out in NTP Classic?

It's 3 tests, I commented them out because I may have a better understanding of 
why they aren't working after the rest of the conversion is done.  It's a waste 
of time trying to figure it out now.  It is 3 tests of 97.

I will fix them at the end.


> Ok.  Expand that a bit for me, please.   The development model of the Google
> Test project changed to one incompatible with the NTPsec project?  Or the
> development model of the NTPsec project changed to one incompatible with the
> Google Test project?

The first.  they recommend you include the entire project within your project in 
order to use it.  Also, there are some quirks running it with C code that did 
not exist before -- not back in 2010.


> I am inclined agree to want the tests in standard C99 C instead of C++, but
> also it needs to bring a value-add, such as making it easier for non-core
> contributors to write new tests and run them.

This is one of the main reasons why I am doing this I stated that in my first 
email: to make it easier to maintain and do regression tests.


> Ok.  Do please email to devel at ntpsec.org each time you convert another test,
> and what the test was that you converted.

If you look at the commit logs you can see that I'm converting each batch one by 
one.  If you subscribe to vc at ntpsec.org you will see the commit logs.  The name 
of the tests and files speak for themselves.  Documentation for these tests 
already exist at:

  https://support.ntp.org/bin/view/Dev/NtpdFunctionMap
  https://support.ntp.org/bin/view/Dev/UnitTestingNotes

I will be creating better documentation for this at the end which will be 
combined with the new test harness.


> I'm pushing really hard on the tests because getting all the tests running is a
> good marker for 0.9.1, and also once we have that working, I'm going to ask you
> to go back and start the work to waf-ify the fork point and forward, so we can
> get bisect to work.

I have explained what we need to do in order to get this to work it is far more 
than just the build system.

We need to coalesce commits and re-play them over the fork point with 
pre-commit building to ensure they work.

The current build system as-is can be used for this as long as we rename all the 
defines and do the file moves right at the start point.

Just doing the build system does not ensure each commit actually builds which is 
the whole point of making bisect useful.

If it's easier think of it this way.  The development done now was done to 
figure out what we need to build on our platforms.  Now that we know this we 
push the build system to the front and put everything on top of it.  With what 
we have now this ensures every commit will actually build which is something 
that was not possible before since we did not know what we needed


Amar.