Some issues about nsswitch regressions tests
Regression tests for resolver-related parts
There is already a regression test in src/tools/regression for gethosty*() and friends. It's main purpose is to check the correctness of these functions in the multithreaded environment. There is also a need in the test, which would check the correctness of these functions' results itself. I see several possible ways:
- We can check that different functions return equal results for the equal queries. This check is a bit redundant for the getipnodeby**(), because they are now implemented via gethostby**() functions. Still it's useful even here, to be sure that implementation is correct. Much more interesting is to compare gethostby*() results with getaddrinfo() results. The idea is that we can always map the gethostbyname2() arguments to the getaddrinfo() arguments using these rules:
- hostname parameter goes as it is
- af parameter is mapped to hints.ai_family
- servname getaddrinfo() argument is NULL and other hints structure fields are set to 0
- if IPv4 to IPv6 mapping is turned off and af is AF_INET6, then we should note, that getaddrinfo() can return broader result set
- We can check the returned struct hostent * by using several rules:
- check that all numerical values are in the correct range
- check that all char * values, that have to be not NULL are not NULL
- check that address length is right, according to the address type
- check that if the address should have been IPv4-to-IPv6 mapped, it was mapped correctly
- The similar checks can be done with struct addrinfo.
Regression tests for passwd, groups, protocols, networks, rpc and services
Checks for these databases will be done in these ways:
- Obtain the whole entities list using get**ent() functions. Then do it again and compare the lists. They, should be the same. Actually, with the current state of nsswitch, guarantees on the get**ent() results are very limited, so this test probably shouldn't be fatal - i.e. we can only give warning, not an error, if the results list are different.
- For each of the obtained entities, make the *byname() request, then make the *byid() request and compare the results - they should be equal.
- For all the queries, that would be made, the results should be checked for correctness (no NULL ptrs, where they shouldn't be, correct numbers, etc).
2-stage testing idea
The idea of this kind of testing is that the nsswitch-query results should be generally the same after the system upgrade (if we don't edit user database, or services file, of course). The test procedure can be very simple: we make a set of nsswitch-queries (with get**ent() and then with get**byname() and get**byid()) and store them in the file (we can use cached's marshalling functions for that). When the test is done next time, it does the same queries in the same order and compares their results to the ones, that are already stored.
The main purpose of such a test is to check the compatibility of different versions of the system. For example, we can take FreeBSD6-STABLE, run the first stage of the test, then upgrade to CURRENT and run the second stage of the test. The test will show all the compatibility issues between versions of nsswitch-dependant functions.