Add framework for testing protocol scanners #111
Conversation
This adds a mock SOCKS5 proxy to be able to test protocol scanners. It creates a single-threaded SOCKS5 proxy on localhost which processes connection requests and dispatches them to a test-specific interface, which can do further testing of the protocol specifics. Currently this just tests available/not available for all protocols. This is not great, but it gives surprisingly much test coverage at the moment. This will likely go down once more protocols scanners do deeper probing, however.
|
Awesome! I really like the testing interface! And the obvious jump in coverage... The one thing that concerns me about this is the amount of code in the test bed dedicated to mocking the socks5 connection - I feel that we should be able to wrap around that interface and not have to worry about it when testing protocols - ideally there should be no need to launch actual networking code at all. This likely means abstracting out some of the networking, but I think the overall result will be cleaner, and minimize the amount of testing code needed. I also think there is an awful lot of commonality in these current protocol scans that we can factor out (e.g. simply connected to a server and checking availability is applicable to a large number of current scans. So is scraping the software banner.) - too offbeat for this PR, but probably worth mentioning. On a similar testing front @emanchado cooked up a potential integration test base: https://github.com/emanchado/onionscan-test - when it comes to testing tricky edge cases like weird redirects, or oddly served certificates, I think having a real test server implementing these things might be an easier option - which would leave the jobs of these unit tests to sanity check port correctness, server hangs (and maybe a tiny bit of application layer stuff). |
This adds a mock SOCKS5 proxy to be able to test protocol scanners. It creates a single-threaded SOCKS5 proxy on localhost which processes connection requests and dispatches them to a test-specific
interface (it makes no actual outgoing connections), which can do further testing of the protocol specifics.
Currently this just tests available/not available for all protocols. This is not great, but it gives surprisingly much test coverage at the moment. This will likely go down once more protocols scanners do deeper
probing, however.