[tor-dev] Proc Unit Testing & Next Project

[Damian Johnson]

Hi Erik, hi Megan.

> Megan and I have finished a first run at writing unit tests for the proc utilities in stem.

Looks great! I only got down to 'test_get_memory_usage()' before
needing to run to catch the bus but the tests that I've seen so far
look good. The mocking though confused me for a bit.

> +def mock_fn(exp_args, return_vals, target=None):
> +  """
> +  Provides a lambda function that may be used to mock another function.

In reading the following code I suspect that this could be clearer if
it accepted a single argument that was the dict of 'argument => return
value'.

> +  :param list of tuples exp_args: expected input value(s) to be used for comparison

The ReStructuredTest format for param entries are...
:param [type ]arg_name:

So to properly compile this should be...
:param list exp_args:

Usually I say what the list contains in the following description.

> +  :param function target: target function to be called if mocking doesn't cover this input

Why do you fall through to the target function? Unit tests need to be
os independent, so if falling though to an os will break on some
platforms then we'll need to find an alternative.

Speaking of os independence, if it isn't too hard would you mind
running this on a warty platform like Windows? If you don't have a
Windows system laying around then don't worry about it.

Don't worry if the expand_path unit test breaks - that's something
Beck is currently fixing.

> +  :precondition: len(exp_args) = len(return_vals)

I checked the sphinx index [1] and python domain [2] for
"precondition" and didn't find it. Are you sure that directive exists?
If not then we can simply provide it in the above function
description.

> +                                                 return_vals[i]    a=exp_args[i]
> +  :returns:  function _mocker such that: f(*a) = target(*a)        a != exp_args[i] and target != N
> +                                                 raise TargetError a != exp_args[i] and target = No

Nice, though to make this render the way that you want in sphinx it
should be changed to...

:returns:  function _mocker such that...
  * return_vals[i]    a = exp_args[i]
  * target(*a)        a != exp_args[i] and target != N
  * raise TargetError a != exp_args[i] and target = No

> +  Used with the builtin zip function to create all possible combinations
> +  of two lists. Called in test_get_stats().

That sounds a lot like itertools.product().

>>> import itertools
>>> list(itertools.product([1, 2, 3], ['a', 'b', 'c']))
[(1, 'a'), (1, 'b'), (1, 'c'), (2, 'a'), (2, 'b'), (2, 'c'), (3, 'a'),
(3, 'b'), (3, 'c')]

> Looking further into the future, we discussed our next project with Stem with Professor Danner today, and agreed that the "Export Tor Desciptors" project would be ideal.

Ok. Little more context on that project in case you're not on tor-dev at ...
https://lists.torproject.org/pipermail/tor-dev/2012-June/003634.html

I was gonna suggest a python port of Onionoo [3][4], which is the
service that supports Atlas [5]. Karsten would be able to help mentor
that, and it would involve filling in the missing bits of descriptor
parsing that we'll need for it (such as network status entries).
However, that would be far more ambitious and might be a bit too
large. Up to you.

Cheers! -Damian

[1] http://sphinx.pocoo.org/genindex.html
[2] http://sphinx.pocoo.org/domains.html#directive-py:class
[3] https://www.torproject.org/projects/onionoo.html
[4] https://gitweb.torproject.org/onionoo.git/blob/HEAD:/DESIGN
[5] https://atlas.torproject.org/