c-ares/test/.gitignore

*.o
libgtest.a
libgmock.a
arestest
aresfuzz
aresfuzzname
arestest.log
arestest.trs
fuzzcheck.sh.log
fuzzcheck.sh.trs
test-suite.log
fuzzoutput
config.h.in
config.h
dnsdump
ares-libfuzzer
ares-libfuzzer-name
libFuzzer.a
Fuzzer
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			`*.o`
			`libgtest.a`
			`libgmock.a`
			`arestest`
			`aresfuzz`
test: ignore aresfuzzname binary 8 years ago			`aresfuzzname`
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.log`
			`arestest.trs`
test: add fuzzing check script to tests Add a test script that runs the fuzzing command over the corpus of DNS packets. This doesn't actually do any fuzzing (it just runs them as inputs without generating any variations) but it does ensure that the fuzzing entrypoint is still working. 9 years ago			`fuzzcheck.sh.log`
			`fuzzcheck.sh.trs`
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-suite.log`
test: Get test code building under Windows - 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 9 years ago			`fuzzoutput`
			`config.h.in`
test: Add utility to show DNS packet from file 9 years ago			`config.h`
test: add fuzz entrypoint for ares_create_query() 8 years ago			`dnsdump`
			`ares-libfuzzer`
			`ares-libfuzzer-name`
			`libFuzzer.a`
			`Fuzzer`