Hi,
I would like to help with the unit tests for Torsocks, I was thinking of starting with utils and config-file tests, does this sound like a reasonable place to start?
regards,
Luke
Hi Luke,
That would be awesome!
Currently, I've already added some basic DNS tests and also unit test for some subsystem in common/.
It uses libtap and integrated with make check also right now.
So yes, please if you like to contribute more tests, that would be great!
Cheers! David
On 06 Sep (09:48:03), Luke Gallagher wrote:
Hi,
I would like to help with the unit tests for Torsocks, I was thinking of starting with utils and config-file tests, does this sound like a reasonable place to start?
regards,
Luke _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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
On 06 Sep (10:12:08), Luke Gallagher wrote:
On 6/09/13 9:52 AM, David Goulet wrote:
So yes, please if you like to contribute more tests, that would be great!
Great, thanks David.
I'll make a start then and be in touch if I have any more queries regarding the tests.
regards,
Luke
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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)?
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?
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?
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?
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
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
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
Hi David,
Just wanted to give you a heads up to let you know that I'm back looking at the tests for torsocks, as its has been a while since the last few commits for tests (things got a little busy towards the end of last year). I'm continuing on from where I left off which is getting some tests in place for socks5 subsystem. I hope that's ok, let me know if there are any problems. I'll be in touch on irc/email if needed.
regards,
Luke
On 27 Jan (14:58:04), Luke Gallagher wrote:
Hi David,
Just wanted to give you a heads up to let you know that I'm back looking at the tests for torsocks, as its has been a while since the last few commits for tests (things got a little busy towards the end of last year). I'm continuing on from where I left off which is getting some tests in place for socks5 subsystem. I hope that's ok, let me know if there are any problems. I'll be in touch on irc/email if needed.
Hey Luke!
No this is great! Please continue, I'll be able to respond quickly to you. The more the merrier! :)
I have a bunch of fixes from Nick's review so things will move a bit around.
Cheers! David
regards,
Luke
-
David Goulet -
Luke Gallagher