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... > > Is there anything else you had in mind for the tests in general? > > > 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. > > > 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. 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. Hope this helps! Any thoughts are welcome! Cheers! David > > > > regards, > > Luke > > > > On 6/09/13 10:14 AM, David Goulet wrote: >> Sure and please don't hesitate to ask any questions or any comments! >> >> You can find me on IRC if you'll like to discuss things. >> >> Cheers! >> David >> >
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev