c-ares

1713 Commits

14 Branches

96 Tags

22 MiB

Tag: Branch: Tree: 728dc8d058

Commit Graph

Author	SHA1	Message	Date
David Drysdale	567e21ec2c	test: drop superfluous fuzz inputs Where there are multiple fuzz input files that only differ in the first two bytes (the query ID), just keep the first such file.	9 years ago
David Drysdale	d52df9123f	test: Add corpus of DNS packets For fuzz testing it is useful to start from a corpus of valid packets, so fill out the test/fuzzinput/ directory with a bunch of inputs. These packets were generated by temporarily modifying the c-ares process_answer() function to save off any incoming response messages.	9 years ago
David Drysdale	af3ee9a8ba	test: Add initial unit tests for c-ares library 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.	9 years ago

Author

SHA1

Message

Date

David Drysdale

567e21ec2c

test: drop superfluous fuzz inputs

Where there are multiple fuzz input files that only differ in
the first two bytes (the query ID), just keep the first such
file.

9 years ago

David Drysdale

d52df9123f

test: Add corpus of DNS packets

For fuzz testing it is useful to start from a corpus of valid
packets, so fill out the test/fuzzinput/ directory with a bunch
of inputs.

These packets were generated by temporarily modifying the c-ares
process_answer() function to save off any incoming response messages.

9 years ago

David Drysdale

af3ee9a8ba

test: Add initial unit tests for c-ares library

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.

9 years ago

3 Commits (728dc8d058021180cc2c24f0c3b289370f08eda4)