Commit Graph

8 Commits

Author SHA1 Message Date
Nick Mathewson
57699de005 Update the copyright year. 2016-02-27 18:48:19 +01:00
Nick Mathewson
f54e54b0b4 Bump copyright dates to 2015, in case someday this matters. 2015-01-02 14:27:39 -05:00
Nick Mathewson
e85f0c650c Merge branch 'resolvemyaddr_squashed' 2014-12-29 10:00:34 -05:00
rl1987
a56511e594 Fix a few comments 2014-12-29 09:59:14 -05:00
Nick Mathewson
fcdcb377a4 Add another year to our copyright dates.
Because in 95 years, we or our successors will surely care about
enforcing the BSD license terms on this code.  Right?
2014-10-28 15:30:16 -04:00
Nick Mathewson
b6e8c74667 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 15:22:16 -04:00
Nick Mathewson
a3e0a87d95 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-07-10 15:20:10 -04:00
Nick Mathewson
f7d654b81e 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-07-10 15:20:09 -04:00