[tor-dev] GSOC Proposal - Improving test coverage for tor

Nick Mathewson nickm at alum.mit.edu
Mon Mar 10 16:40:08 UTC 2014


On Sun, Mar 9, 2014 at 7:37 PM, Qingping Hou <dave2008713 at gmail.com> wrote:
> Hi Punit,
>
> Unit test for individual functions are written in C (see src/test in
> Tor repo). Chutney + Stem is probably more suitable for integration
> test.

Right.  If you want to do integration tests, you'll be using Chutney +
Stem.  If you want to write unit tests, you'll be using the
infrastructure in src/test/test_* .

When picking a function or set of functions to write a test for,
consider that the purpose of a GSoC application is to demonstrate to
the mentor organization that you'll be able to do what they hope
you'll be able to do.

So, what functions do we hope will be tested by the end of the summer?
Most likely: tricky functions that perform complex behavior, that and
have an important role in the Tor process.

Naturally, we don't expect that a student will be at full strength at
the start of the process, but we'd like a sense of what you're able to
do now, and how you approach a problem that presents a challenge.  For
example, in circuituse.c, I would be shocked if a student just
starting with Tor were able to write a good set of tests for
connection_ap_handshake_attach_circuit() or circuit_expire_building()
-- those are tricky, nasty functions. But on the other hand wouldn't
be impressed by an applicant who thought that testing
circuit_enough_testing_circuits() was a good way to demonstrate their
abilities -- as a function, it's just too simple.

Of that list of files you mentioned, I'd suggest that
connection_edge.c probably has some good candidate functions for being
not so hard to understand, but being tricky enough to represent a good
way for a student to show their ability.

best wishes,
-- 
Nick


More information about the tor-dev mailing list