This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: Test hook for nss_files testing
- From: Stan Shebs <stanshebs at google dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 11 Jan 2016 16:00:44 -0600
- Subject: Re: RFC: Test hook for nss_files testing
- Authentication-results: sourceware.org; auth=none
- References: <5664991E dot 4090105 at redhat dot com> <5665BA0A dot 50504 at redhat dot com> <5665D13C dot 1040703 at redhat dot com> <5665F130 dot 1040209 at redhat dot com> <56698F52 dot 2040008 at redhat dot com> <566A728A dot 1060903 at redhat dot com> <566ABE60 dot 9090601 at redhat dot com> <566AE707 dot 8050702 at redhat dot com>
On Fri, Dec 11, 2015 at 9:08 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 12/11/2015 07:15 AM, Florian Weimer wrote:
> > On 12/11/2015 07:51 AM, Carlos O'Donell wrote:
> >
> >>> I'm not so sure. Setting up the chroot in a realistic way is quite
> >>> difficult. You need to populat /dev and /dev/pts in some way, and
> >>> arrange for the necessary GCC and platform bits being present, whatever
> >>> they are. âmake installâ may not actually produce a tree layout that is
> >>> used by any downstream distribution. And so on. The list of issues is
> >>> quite long.
> >>
> >> In which regard do you think this is not ideal?
> >
> > It's quite a bit of work and very tightly integrated with individual
> > distributions. Test hooks and in-tree testing directly benefit everyone
> > who looks at test results.
>
> You raise a good point here and that's perhaps the strongest argument
> I've heard in favour of white-box testing for this particular interface.
>
One of the bits of religion I've gotten at Google is that one wants white-box
hooks for unit testing because the tests may be running in exotic and/or
highly-restricted contexts, and your chances of getting a code path executed
are better if you can write a custom test executable that drives the library
down that path.
Stan