Aim is to ensure that code coverage information can escape the
container. To do this:
- Enter a new mount namespace too, so that we can...
- Bind mount the expected source directory into the container
- Share memory with the sub-process so coverage information is
shared too.
On Linux we can potentially use user and UTS namespaces to run a test
in a pseudo-container with:
- arbitrary filesystem (e.g. /etc/resolv.conf, /etc/nsswitch.conf, /etc/hosts)
- arbitrary hostname/domainname.
Include a first pass at the framework code to allow this, along with a
first test case that uses the container.
- Initial nmake file based off library nmake file
- Cast socket call arguments to (char *)
- Use wrapper sclose() that maps to closesocket() or close()
- Build a config.h indicating presence of headers
- Conditionally include netdb.h
- Remove unnecessary include of sys/socket.h
- Force longer bitmask for allocation failure tracking
- Call WSAStartup() / WSACleanup() in main()
- Set TCP_NODELAY for mock server
- Turn on tests in AppVeyor build
- Update the MockServer to allow separate specification of
UDP and TCP ports
- Have an array of mock servers listening on consecutive
sets of ports.
- Rename Process(fd) to ProcessFD(fd) to avoid confusion.
- Initialize channel by using the new ares_set_servers_ports()
entrypoint, so multiple ports on the same loopback address
can be used.
- Make mock server listen on UDP + TCP in parallel.
- Test UDP->TCP fallback on truncation
- Test EDNS->no-EDNS fallback
- Test some environment init options
- Test nonsense reply
test: short response
The tests are written in C++11, using the GoogleTest and GoogleMock
frameworks. They have their own independent autoconf setup, so that
users of the library need not have a C++ compiler just to get c-ares
working (however, the test/configure.ac file does assume the use of
a shared top-level m4/ directory). However, this autoconf setup has
only been tested on Linux and OSX so far.
Run with "./arestest", or "./arestest -v" to see extra debug info.
The GoogleTest options for running specific tests are also
available (e.g. "./arestest --gtest_filter=*Live*").
The tests are nowhere near complete yet (currently hitting around
60% coverage as reported by gcov), but they do include examples
of a few different styles of testing:
- There are live tests (ares-test-live.cc), which assume that the
current machine has a valid DNS setup and connection to the
internet; these tests issue queries for real domains but don't
particularly check what gets returned. The tests will fail on
an offline machine.
- There a few mock tests (ares-test-mock.cc) that set up a fake DNS
server and inject its port into the c-ares library configuration.
These tests allow specific response messages to be crafted and
injected, and so are likely to be used for many more tests in
future.
- To make this generation/injection easier, the dns-proto.h file
includes C++ helper classes for building DNS packets.
- Other library entrypoints that don't require network activity
(e.g. ares_parse_*_reply) are tested directly.
- There are few tests of library-internal functions that are not
normally visible to API users (in ares-test-internal.cc).
- A couple of the tests use a helper method of the test fixture to
inject memory allocation failures, using the earlier change to the
library to allow override of malloc/realloc/free.
- There is also an entrypoint to allow Clang's libfuzzer to drive
the packet parsing code in ares_parse_*_reply, together with a
standalone wrapper for it (./aresfuzz) to allow use of afl-fuzz
for further fuzz testing.
David Drysdale