Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chewie.py is not really tested here. #47

Open
Bairdo opened this issue Sep 25, 2018 · 1 comment
Open

chewie.py is not really tested here. #47

Bairdo opened this issue Sep 25, 2018 · 1 comment

Comments

@Bairdo
Copy link
Contributor

Bairdo commented Sep 25, 2018

#39 adds some tests, but more would be good.

look into mocking the socket operations.

@samrussell
Copy link
Collaborator

it would be better to refactor out the network-level stuff into its own classes - potentially a couple for the IO handling,, deserialising from the wire, and parsing the messages

that way we can test the following parts of the journey individually:

  • socket IO lifecycle (port up/down, connection closed, device disappearing, probably easier tested offline as these classes shouldn't change once they're working)
  • deserialising data into something meaningful (address/serialised message data)
  • deserialising messages
  • routing messages to the correct state machine
  • serialising messages
  • serialising serialised message + metadata into something to go in a packet
  • socket IO lifecycle (as above)

im working on a raw packet IO lifecycle class at samrussell/rawserver and we probably want a similar one for the UDP packets, and once it's ready we should have a slightly higher level option that just calls the handler and plays nicely with eventlet

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants