Turning TESTS on by default
Kubilay Kocak
koobs at FreeBSD.org
Sat Jun 7 01:29:03 UTC 2014
On 7/06/2014 5:14 AM, Julio Merino wrote:
> Hello all,
>
>
> TL;DR
> -----
>
> I plan to turn the TESTS src.conf knob ON by default on Tuesday once I
> have been able to perform enough sanity-checks of the build and all of
> them pass.
>
> The impact of this is that the FreeBSD Test Suite (see tests(7)) will
> be built and installed by default under /usr/tests/ along with the
> private atf libraries and binaries. There should be no other changes
> and this should be transparent to everyone.
>
> If this happens to break the world in any way, we can trivially roll
> the change back to fix the fallout.
>
>
> Some details
> ------------
>
> TESTS was never intended to be disabled by default. However, the
> original patches that were committed months ago related to this
> feature broke the build and the easiest way out (instead of reverting
> the commits) was to set the knob to disabled. Unfortunately, it stayed
> that way even after the discovered problems were fixed.
>
> I am confident enough now that we have ironed out all major issues
> that this might introduce, so it is about time to enable TESTS by
> default again in HEAD.
>
> The benefits of this are that 1) we allow end users (especially
> consumers of binary releases!) to run the tests out of the box, as it
> has always been intended; and 2) we will be able to run the official
> release builds through testing via Jenkins, instead of having to issue
> custom builds.
>
> Actual change: https://phabric.freebsd.org/D188
>
>
> I will update this thread when the change is committed and/or with any updates.
>
> Please let me know if I'm missing anything.
>
> Cheers
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
Julio,
Awesome! I look forward to automated review lint checks that test for
addition of tests, coverage++ and issue ID's in a changeset :]
On a related note, how challenging might it be to generate and expose
coverage metrics?
This is not to say they are a perfect measure of anything in particular,
but ought to provide us a good high level idea of important candidate
areas that would benefit from coverage and don't currently.
--
Koobs
More information about the freebsd-current
mailing list