Support for lower-level TCP and UDP connections

[nyurik]

Mockito does a great job at the HTTP level, but at times I would like to test lower level clients that send UDP or TCP packets. While this is clearly different from the server.mock(...) -> Mock object, some of the mockito infrastructure may still apply.

Usage example:

let mut s = mockito::Server::new();

s.mock_udp()
  .match_size(3) // expect 3-byte message
  .match_body(b'123') // expect message matching these bytes
  .with_body(b'456') // respond with these bytes
  .create();

Other matching could help examine the received data, validate it, respond differently depending on the content, etc

P.S. https://github.com/thomasarmel/socket-server-mocker is a similar effort that might benefit from joining mockito project?

[nyurik]

The above content was reported to github - its an .exe and a .dll file, clearly unrelated, and likely dangerous. The user account was later deleted.

[nyurik]

@lipanski please delete the above post by "ghost" - the account was deleted, and it links to a virus.

[lipanski]

@nyurik sounds interesting but I think I would have to introduce a new type TcpServer (and UdpServer) since otherwise the validation rules on the existing and new matchers would get quite complex and hard to follow (internally). at that point I wonder if https://github.com/thomasarmel/socket-server-mocker is enough to cover your use case or what are you missing from that crate? generally I try to keep mockito fairly minimal/contained, even though we're way beyond minimal by now :smile_cat:

[nyurik]

Yeah, I was a bit torn on that one too. We would definitely need separate TCP and UDP servers. The infrastructure to keep a pool of them, communication channels between the server and the testing framework, assertion that a mock has been executed, and possibly other plumbing might be relevant. Async stuff might also be highly desirable, and a bit of a pain to duplicate.

HTTP is fundamentally based on request response, while (in theory) TCP / UDP could be more of an independent two way communication / time based /..., although of course most cases it will still be a simple request/response, only at a lower - bytes level.

So if it would be possible to reuse the plumbing, while providing separate set of servers and expectation API, it would be a good addition to your lib - one stop network testing harness. If not, than yeah, a separate lib that replicates a lot of the hard work you did.

The biggest issue with the socket-server-mocker is that it is relatively new and has some rough around the edges spots that will need to be worked through.