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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
