3 ms·

I've _just_ published this package, so all of this is quite new! It lets you define mock behaviour for a WebRTC peer in a couple of lines, and then connect to

I've _just_ published this package, so all of this is quite new! It lets you define mock behaviour for a WebRTC peer in a couple of lines, and then connect to that mock using normal WebRTC APIs so you can write automated tests against reliable fake remote peers, quickly & easily. It can also proxy WebRTC traffic, basically by creating two connections and passing data & media between them, and then hooking setup methods to automatically redirect your traffic through those. You just set up the hooks on your connection, then you connect to a real remote peer as normal, and everything gets intercepted (and then it can be rewritten, recorded, whatever you like). At the moment the API is a little small, but all the traffic is intercepted and modifiable now, so extending that to cover whatever behaviours might be interesting should be relatively simple from here on, it's just a question of what to include. I've mostly focused on datachannels since that's more what I'm interested in right now, but ideas for more mock behaviours you'd find useful would be really helpful. Suggestions very welcome!

dboreham 4y ago
Having done a bit of this: wondering why you didn't use the real WebRTC stack with a test-oriented signaling implementation?
- pimterry 4y ago
  This does use a real WebRTC stack (specifically libdatachannel - https://libdatachannel.org https://libdatachannel.org). Under the hood this is making real WebRTC connections. But I guess you mean why it doesn't mock using real peers in the browser where the tests are happening, using the browser's existing stack there? There's a few reasons I've avoided that: * Primarily: I want to do things that the browser APIs won't let you do. E.g. sending invalid data, or intentionally causing various types of errors. The browser APIs are designed to stop you doing the wrong thing, by keeping the raw data at arm's length. Very sensible for normal WebRTC usage, but bad for testing edge cases and breaking things. * Similarly I want access to the raw RTP data, to derive metrics, track metadata, and generally fiddle around with it. AFAIK browsers only let you access processed video, not the raw packets. * I want to use this to build a WebRTC proxy, and then independently launch one or more browsers and redirect their traffic through it, which means the proxy has to live independently from the browsers (and I don't want to launch a whole separate headless browser instance just to 'host' that proxy). * I want the option to intercept WebRTC connections from non-browser clients too. Most of that isn't strictly required for the basics, but it's all nice to have, and if you do everything inside the same browser with the standard APIs then it's all completely off the table. If you use a lower-level library, you get a lot more control, and all these become possible.

dboreham 4y ago

Having done a bit of this: wondering why you didn't use the real WebRTC stack with a test-oriented signaling implementation?

pimterry 4y ago
This does use a real WebRTC stack (specifically libdatachannel - https://libdatachannel.org https://libdatachannel.org). Under the hood this is making real WebRTC connections. But I guess you mean why it doesn't mock using real peers in the browser where the tests are happening, using the browser's existing stack there? There's a few reasons I've avoided that: * Primarily: I want to do things that the browser APIs won't let you do. E.g. sending invalid data, or intentionally causing various types of errors. The browser APIs are designed to stop you doing the wrong thing, by keeping the raw data at arm's length. Very sensible for normal WebRTC usage, but bad for testing edge cases and breaking things. * Similarly I want access to the raw RTP data, to derive metrics, track metadata, and generally fiddle around with it. AFAIK browsers only let you access processed video, not the raw packets. * I want to use this to build a WebRTC proxy, and then independently launch one or more browsers and redirect their traffic through it, which means the proxy has to live independently from the browsers (and I don't want to launch a whole separate headless browser instance just to 'host' that proxy). * I want the option to intercept WebRTC connections from non-browser clients too. Most of that isn't strictly required for the basics, but it's all nice to have, and if you do everything inside the same browser with the standard APIs then it's all completely off the table. If you use a lower-level library, you get a lot more control, and all these become possible.