tor/changes/fancy_testing

  o Build features:

    - Tor now builds each source file in two modes: a mode that avoids
      exposing identifiers needlessly, and another mode that exposes
      more identifiers for testing. This lets the compiler do better at
      optimizing the production code, while enabling us to take more
      radical measures to let the unit tests test things.

    - The production builds no longer include functions used only
      in the unit tests; all functions exposed from a module for
      unit-testing only are now static in production builds.

    - Add an --enable-coverage configuration option to make the unit
      tests (and a new src/or/tor-cov target) to build with gcov test
      coverage support.

  o Testing:

    - We now have rudimentary function mocking support that our unit
      tests can use to test functions in isolation. Function mocking
      lets the tests temporarily replace a function's dependencies with
      stub functions, so that the tests can check the function without
      invoking the other functions it calls.
Start work on fancy compiler tricks to expose extra stuff to our tests This is mainly a matter of automake trickery: we build each static library in two versions now: one with the TOR_UNIT_TESTS macro defined, and one without. When TOR_UNIT_TESTS is defined, we can enable mocking and expose more functions. When it's not defined, we can lock the binary down more. The alternatives would be to have alternate build modes: a "testing configuration" for building the libraries with test support, and a "production configuration" for building them without. I don't favor that approach, since I think it would mean more people runnning binaries build for testing, or more people not running unit tests. 2013-06-06 20:56:05 +02:00			`o Build features:`

			`- Tor now builds each source file in two modes: a mode that avoids`
			`exposing identifiers needlessly, and another mode that exposes`
			`more identifiers for testing. This lets the compiler do better at`
			`optimizing the production code, while enabling us to take more`
			`radical measures to let the unit tests test things.`

Completely refactor how FILENAME_PRIVATE works We previously used FILENAME_PRIVATE identifiers mostly for identifiers exposed only to the unit tests... but also for identifiers exposed to the benchmarker, and sometimes for identifiers exposed to a similar module, and occasionally for no really good reason at all. Now, we use FILENAME_PRIVATE identifiers for identifiers shared by Tor and the unit tests. They should be defined static when we aren't building the unit test, and globally visible otherwise. (The STATIC macro will keep us honest here.) For identifiers used only by the unit tests and never by Tor at all, on the other hand, we wrap them in #ifdef TOR_UNIT_TESTS. This is not the motivating use case for the split test/non-test build system; it's just a test example to see how it works, and to take a chance to clean up the code a little. 2013-06-06 23:58:28 +02:00			`- The production builds no longer include functions used only`
			`in the unit tests; all functions exposed from a module for`
			`unit-testing only are now static in production builds.`
Start work on fancy compiler tricks to expose extra stuff to our tests This is mainly a matter of automake trickery: we build each static library in two versions now: one with the TOR_UNIT_TESTS macro defined, and one without. When TOR_UNIT_TESTS is defined, we can enable mocking and expose more functions. When it's not defined, we can lock the binary down more. The alternatives would be to have alternate build modes: a "testing configuration" for building the libraries with test support, and a "production configuration" for building them without. I don't favor that approach, since I think it would mean more people runnning binaries build for testing, or more people not running unit tests. 2013-06-06 20:56:05 +02:00
Coverage support: build with --enable-coverage to have tests run with gcov If you pass the --enable-coverage flag on the command line, we build our testing binaries with appropriate options eo enable coverage testing. We also build a "tor-cov" binary that has coverage enabled, for integration tests. On recent OSX versions, test coverage only works with clang, not gcc. So we warn about that. Also add a contrib/coverage script to actually run gcov with the appropriate options to generate useful .gcov files. (Thanks to automake, the .o files will not have the names that gcov expects to find.) Also, remove generated gcda and gcno files on clean. 2013-07-09 18:37:11 +02:00			`- Add an --enable-coverage configuration option to make the unit`
			`tests (and a new src/or/tor-cov target) to build with gcov test`
			`coverage support.`

Add rudimentary test mocking support. This is not the most beautiful possible implementation (it requires decorating mockable functions with ugly macros), but it actually works, and is portable across multiple compilers and architectures. 2013-07-10 21:03:01 +02:00			`o Testing:`

			`- We now have rudimentary function mocking support that our unit`
			`tests can use to test functions in isolation. Function mocking`
			`lets the tests temporarily replace a function's dependencies with`
			`stub functions, so that the tests can check the function without`
			`invoking the other functions it calls.`