[tor-dev] Torsocks tests

[Luke Gallagher]

Hi David,

On 12/09/13 11:57 PM, David Goulet wrote:
> Hi Luke!
> 
> Luke Gallagher:
>> Hi David,
>> 
>> I would like to make sure I'm heading in the right direction with
>> the tests and have a few questions which I've compiled below:
>> 
>> 
>> First of all generally speaking:
>> 
>> I've taken the approach: if a declaration is defined in the
>> header file then I'll aim to write tests for it, if it makes
>> sense to do so. Is this the right approach? Or is the aim to
>> isolate and test as much of the code as possible (including
>> non-exposed declarations)?
> 
> Torsocks is quite a small code base but with a lot of entry point
> that touches quite a few things. Thus, my approach would be two
> separate things into two "big" category, unit tests and
> feature/regression tests.
> 
> For instance, testing config-file.c/.h, I see that as a unit test
> which make sure that data structure and parsing makes sense in
> different cases (bad and good).
> 
> As for the libc declaration such as gethostbyname, it's a
> combination of every subsystem of Torsocks thus being features and
> testing them to make sure they work well and behave right also when
> using them wrong.
> 
> That being said, a good approach is to begin to unit test every
> subsystem such as the connection API for instance and socks5,
> config-file, etc... Once we are sure that those behave right in
> good and bad cases, the foundation to test features are more
> solid.
> 
> In a nutshell, let's get as much as possible code coverage of
> src/common stuff and than build test for torsocks features like DNS
> query, multi threading, etc...
> 

Thanks, that all makes sense. I'll focus on the unit tests first and
then worry about the feature/regression tests after that.


>> 
>> 
>> common/config-file tests:
>> 
>> I have a single test for config_file_read which tests the
>> behaviour when there is no config file given. Does it make sense
>> to take this further and setup fixtures to test different config
>> files on disk, for example an empty config file, bad config file,
>> etc?
> 
> Yes! Bad configuration can happen all the time and it's *VERY*
> important to avoid bad value(s) being put in that results in
> connection going off Tor for instance.

Great, I'll keep moving ahead with this and get a few different test
cases happening.

>> 
>> 
>> common/socks5 tests:
>> 
>> At this point it is a little unclear on the best approach to test
>> this. What are the requirements for adequately testing the socks5
>> subsystem?
>> 
>> A few of my thoughts are:
>> 
>> * Unit tests with mocks/stubs to help isolate things *
>> Integration tests similar to the dns tests * A combination of the
>> above * Something else I've missed?
> 
> Socks5 is tricky because each calls actually do I/O ops. on a
> socket. So, a good way here would be probably to simulate a socks5
> server with a simple thread that listen on the socket and check if
> it receives the right values for each socks5 send ops.

Thanks, this sounds like a simpler approach than what I was thinking.
I'll look into this next.


> Testing a full connection to Tor would be more of a feature test
> since *everything* in Torsocks is using that socks5 layer to
> communicate with the Tor daemon.
> 
>> 
>> lib/* tests:
>> 
>> These seem similar to the socks5 tests above, does this sound
>> right? Is there anything obvious that we should not be testing or
>> want to avoid with the tests?
> 
> Like a mention before, these would be feature tests so a bit like
> test_dns.c is doing right now.
> 
> But, this is the more painful part because it's not that trivial to
> test if our connection went through Tor or not. check.tpo is a good
> start for that I guess :). There is some features also like inet
> socket passing through Unix socket that torsocks is suppose to
> deny, some syscall() also, UDP sockets, etc... that can be tested
> quite easily.
Great points, this makes things clearer for getting a good start on
the feature tests.

> 
> Hope this helps! Any thoughts are welcome!
> 
> Cheers! David
> 

Yes that was very helpful, thank you!


regards,

Luke