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
|
|
|
# Where to find the c-ares source code; needed because the tests use library-internal headers
|
|
|
|
ARES_SRC_DIR = ..
|
|
|
|
# Where to find the built c-ares static library
|
|
|
|
ARES_BLD_DIR = ..
|
|
|
|
AUTOMAKE_OPTIONS = foreign
|
|
|
|
ACLOCAL_AMFLAGS = -I ../m4
|
|
|
|
GMOCK_DIR = gmock-1.7.0
|
|
|
|
GTEST_DIR = $(GMOCK_DIR)/gtest
|
|
|
|
# Note use of -isystem to force use of local gMock/gTest even if there's an installed version.
|
|
|
|
CPPFLAGS += -I$(ARES_SRC_DIR) -isystem $(GTEST_DIR)/include -isystem $(GMOCK_DIR)/include
|
|
|
|
CXXFLAGS += -Wall $(PTHREAD_CFLAGS)
|
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
|
|
|
|
|
|
|
# Makefile.inc provides the TESTSOURCES, TESTHEADERS and FUZZSOURCES defines
|
|
|
|
include Makefile.inc
|
|
|
|
|
|
|
|
TESTS = arestest fuzzcheck.sh
|
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
|
|
|
|
|
|
|
noinst_PROGRAMS = arestest aresfuzz aresfuzzname dnsdump
|
|
|
|
arestest_SOURCES = $(TESTSOURCES) $(TESTHEADERS)
|
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
|
|
|
arestest_LDADD = libgmock.la libgtest.la $(ARES_BLD_DIR)/libcares.la $(PTHREAD_LIBS)
|
|
|
|
|
|
|
|
# Not interested in coverage of test code, but linking the test binary needs the coverage option
|
|
|
|
@CODE_COVERAGE_RULES@
|
|
|
|
arestest_LDFLAGS = $(CODE_COVERAGE_LDFLAGS)
|
|
|
|
|
|
|
|
noinst_LTLIBRARIES = libgmock.la libgtest.la
|
|
|
|
|
|
|
|
libgmock_la_SOURCES = $(GMOCK_DIR)/src/gmock-all.cc \
|
|
|
|
$(GMOCK_DIR)/src/gmock-cardinalities.cc \
|
|
|
|
$(GMOCK_DIR)/src/gmock-internal-utils.cc \
|
|
|
|
$(GMOCK_DIR)/src/gmock-matchers.cc \
|
|
|
|
$(GMOCK_DIR)/src/gmock-spec-builders.cc \
|
|
|
|
$(GMOCK_DIR)/src/gmock.cc \
|
|
|
|
$(GMOCK_DIR)/include/gmock/gmock-cardinalities.h \
|
|
|
|
$(GMOCK_DIR)/include/gmock/gmock-generated-matchers.h \
|
|
|
|
$(GMOCK_DIR)/include/gmock/gmock-more-actions.h \
|
|
|
|
$(GMOCK_DIR)/include/gmock/gmock-actions.h \
|
|
|
|
$(GMOCK_DIR)/include/gmock/gmock-generated-actions.h \
|
|
|
|
$(GMOCK_DIR)/include/gmock/gmock-matchers.h \
|
|
|
|
$(GMOCK_DIR)/include/gmock/gmock-generated-function-mockers.h \
|
|
|
|
$(GMOCK_DIR)/include/gmock/gmock.h \
|
|
|
|
$(GMOCK_DIR)/include/gmock/gmock-generated-nice-strict.h \
|
|
|
|
$(GMOCK_DIR)/include/gmock/gmock-spec-builders.h \
|
|
|
|
$(GMOCK_DIR)/include/gmock/internal/gmock-internal-utils.h \
|
|
|
|
$(GMOCK_DIR)/include/gmock/internal/gmock-generated-internal-utils.h \
|
|
|
|
$(GMOCK_DIR)/include/gmock/internal/gmock-port.h \
|
|
|
|
$(GMOCK_DIR)/include/gmock/gmock-more-matchers.h
|
|
|
|
|
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
|
|
|
libgmock_la_CPPFLAGS = -isystem $(GTEST_DIR)/include -I$(GTEST_DIR) -isystem $(GMOCK_DIR)/include -I$(GMOCK_DIR)
|
|
|
|
|
|
|
|
libgtest_la_SOURCES = $(GTEST_DIR)/src/gtest-all.cc \
|
|
|
|
$(GTEST_DIR)/src/gtest.cc \
|
|
|
|
$(GTEST_DIR)/src/gtest-death-test.cc \
|
|
|
|
$(GTEST_DIR)/src/gtest-filepath.cc \
|
|
|
|
$(GTEST_DIR)/src/gtest-port.cc \
|
|
|
|
$(GTEST_DIR)/src/gtest-printers.cc \
|
|
|
|
$(GTEST_DIR)/src/gtest-test-part.cc \
|
|
|
|
$(GTEST_DIR)/src/gtest-typed-test.cc \
|
|
|
|
$(GTEST_DIR)/src/gtest-internal-inl.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/gtest-test-part.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/gtest-param-test.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/gtest-printers.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/gtest-message.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/gtest.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/gtest_pred_impl.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/gtest-death-test.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/gtest-spi.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/gtest-typed-test.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/internal/gtest-filepath.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/internal/gtest-param-util-generated.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/internal/gtest-type-util.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/internal/gtest-string.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/internal/gtest-port.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/internal/gtest-param-util.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/internal/gtest-death-test-internal.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/internal/gtest-linked_ptr.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/internal/gtest-internal.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/internal/gtest-tuple.h \
|
|
|
|
$(GTEST_DIR)/include/gtest/gtest_prod.h
|
|
|
|
|
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
|
|
|
libgtest_la_CPPFLAGS = -isystem $(GTEST_DIR)/include -I$(GTEST_DIR) -isystem $(GMOCK_DIR)/include -I$(GMOCK_DIR)
|
|
|
|
|
|
|
|
aresfuzz_SOURCES = $(FUZZSOURCES)
|
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
|
|
|
aresfuzz_LDADD = $(ARES_BLD_DIR)/libcares.la
|
|
|
|
|
|
|
|
aresfuzzname_SOURCES = $(FUZZNAMESOURCES)
|
|
|
|
aresfuzzname_LDADD = $(ARES_BLD_DIR)/libcares.la
|
|
|
|
|
|
|
|
dnsdump_SOURCES = $(DUMPSOURCES)
|
|
|
|
dnsdump_LDADD = $(ARES_BLD_DIR)/libcares.la
|
|
|
|
|
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
|
|
|
test: check
|