Testing framework for low-level API

[jonathanfine]

I'm just about to make a commit that shows by example a way of writing tests for the low-level API. I quite like it, but I'm biased.

For more information, see the commit that follows.

By the way, I'm more concerned to get right the way we write our tests than the code used to implement it (which at present is a bit messy).

I'd also like to be able to run existing application code through the testing framework so we can see better what it is doing. If we get this right we can reuse this work when we come to create the new API - we can check that the old and new code do the same thing at the connection level.

[dbrgn]

I'm currently working on #13, which should at least provide the base setup for the test suites.

[bennuttall]

@jonathanfine if you're unsure about pushing a commit, maybe fork the repo and push to that, then create a PR against this, and we can discuss.

[jonathanfine]

@bennuttall

Thank you for the suggestion. I think I've done as you suggested.

[bennuttall]

👍

[hashbangstudio]

Have added a set of unittest based tests (had them from python 2 version so easy enough to port over and py.test works with them) and example usages of the API with pull request at #22
Even if people prefer to have only py.test style tests it gives something to test against now and can be changed later.

Pull request uses enum34 package from PyPI https://pypi.python.org/pypi/enum34. Best to be standard library and if it is already backported it means fewer changes in future. This would need to be configured for the Travis build. Opened using this package and adding it to Travis config as issue #23

Work in this pull request should probably be linked/merged with work in #20 to allow for socket tests without actual socket or could work with mock server.