[Twisted-Python] Autobahn WebSockets 0.4.3
New release 0.4.3 of Autobahn WebSockets including: + Hybi-17 support + TLS (secure WebSocket) + lots of new options + improved docs and tutorials + close behavior coverage for testsuite + many small things I forgot Special thanks to Peter Thorson for significant code contributions and fruitful discussions! Peter works on a C++/ASIO-based WebSocket client/server framework you may checkout here https://github.com/zaphoyd/websocketpp Updated Python package is here: http://pypi.python.org/pypi/autobahn Updated test suite reports are available under http://www.tavendo.de/autobahn/testsuite.html including mobile clients and servers. Cheers, Tobias
On Mon, Oct 31, 2011 at 8:21 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
Hi, how do I run the unit tests for Autobahn? Trial doesn't work, and there don't appear to be any instances of unittest's classes in the tree. Also, is it possible to run the Autobahn pub-sub and RPC stuff over a different transport than WebSockets, like plain TCP? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <MostAwesomeDude@gmail.com>
Hi, how do I run the unit tests for Autobahn? Trial doesn't work, and there don't appear to be any instances of unittest's classes in the tree.
Please see here http://www.tavendo.de/autobahn/testsuite.html#test_browsers to get started. What do you want to test? Own client, own server?
Also, is it possible to run the Autobahn pub-sub and RPC stuff over a different transport than WebSockets, like plain TCP?
In principle, the RPC and PubSub protocol is designed to work over * reliable, ordered, full-duplex message channel * any serialization format that supports lists and primitive types Currently, the only binding is WebSocket/JSON. Raw TCP as a transport .. well, you need some message framing anyway. WebSocket is already quite bare metal. What are you thinking of? Whats your use case?
On Mon, Oct 31, 2011 at 2:27 PM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
I wanted to test Autobahn's internals. Unit tests, not integration tests. The integration test stuff is pretty cool, too, but I was hoping for tests which verify Autobahn's behavior internally.
Well, TCP would fulfill the channel, and something like AMP could be the serializer, I guess. I'm not super-picky. I just wanted to know how flexible the whole thing is. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <MostAwesomeDude@gmail.com>
You can use Autobahn to test Autobahn of course. Autobahn's test approach is tailored towards it's domain (communication protocols) and based on the following perspective: If you have a black box, that behaves to a protocol spec regarding all it's externally visible behavior, you can call that black box conforming to the protocol. Whether you then have unit tests for stuff that happens within the black box is less relevant, as long as you have covered all the spec with behavioral test cases. When you only have unit tests for stuff happening inside the box, you still can't say if the box conforms to the spec. It may pass all unit tests and fail when talking to the world. For protocols, the reason for this is: any unit test by definition misses an essential part: the peer you communicate with. As an example, instead of writing a unit test that checks whether a UTF-8 decoding function raises upon invalid sequences, execute a fuzzing test case where the fuzzer will actually send the tested implementation invalid UTF-8 and check the externally visible behavior.
On Mon, Oct 31, 2011 at 3:25 PM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
Okay. This seems reasonable. I really only have two reasons for doing unit tests on top of this, and both are kinda orthogonal: Isolation and specificity. Clearly, I need to do less TDD. Anyway, I'm running the fuzzer against txWS, and things appear to be working. Thanks for a useful tool! -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <MostAwesomeDude@gmail.com>
On Mon, Oct 31, 2011 at 8:21 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
Hi, how do I run the unit tests for Autobahn? Trial doesn't work, and there don't appear to be any instances of unittest's classes in the tree. Also, is it possible to run the Autobahn pub-sub and RPC stuff over a different transport than WebSockets, like plain TCP? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <MostAwesomeDude@gmail.com>
Hi, how do I run the unit tests for Autobahn? Trial doesn't work, and there don't appear to be any instances of unittest's classes in the tree.
Please see here http://www.tavendo.de/autobahn/testsuite.html#test_browsers to get started. What do you want to test? Own client, own server?
Also, is it possible to run the Autobahn pub-sub and RPC stuff over a different transport than WebSockets, like plain TCP?
In principle, the RPC and PubSub protocol is designed to work over * reliable, ordered, full-duplex message channel * any serialization format that supports lists and primitive types Currently, the only binding is WebSocket/JSON. Raw TCP as a transport .. well, you need some message framing anyway. WebSocket is already quite bare metal. What are you thinking of? Whats your use case?
On Mon, Oct 31, 2011 at 2:27 PM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
I wanted to test Autobahn's internals. Unit tests, not integration tests. The integration test stuff is pretty cool, too, but I was hoping for tests which verify Autobahn's behavior internally.
Well, TCP would fulfill the channel, and something like AMP could be the serializer, I guess. I'm not super-picky. I just wanted to know how flexible the whole thing is. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <MostAwesomeDude@gmail.com>
You can use Autobahn to test Autobahn of course. Autobahn's test approach is tailored towards it's domain (communication protocols) and based on the following perspective: If you have a black box, that behaves to a protocol spec regarding all it's externally visible behavior, you can call that black box conforming to the protocol. Whether you then have unit tests for stuff that happens within the black box is less relevant, as long as you have covered all the spec with behavioral test cases. When you only have unit tests for stuff happening inside the box, you still can't say if the box conforms to the spec. It may pass all unit tests and fail when talking to the world. For protocols, the reason for this is: any unit test by definition misses an essential part: the peer you communicate with. As an example, instead of writing a unit test that checks whether a UTF-8 decoding function raises upon invalid sequences, execute a fuzzing test case where the fuzzer will actually send the tested implementation invalid UTF-8 and check the externally visible behavior.
On Mon, Oct 31, 2011 at 3:25 PM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
Okay. This seems reasonable. I really only have two reasons for doing unit tests on top of this, and both are kinda orthogonal: Isolation and specificity. Clearly, I need to do less TDD. Anyway, I'm running the fuzzer against txWS, and things appear to be working. Thanks for a useful tool! -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <MostAwesomeDude@gmail.com>
participants (3)
-
Corbin Simpson -
Iap -
Tobias Oberstein