search

martinpitt / umockdev

Mock hardware devices for creating unit tests and bug reporting
https://launchpad.net/umockdev
GNU Lesser General Public License v2.1
308 stars 55 forks source link

Need help on mocking physical usb device #180

Open siddharthshankarpaul opened 2 years ago

siddharthshankarpaul commented 2 years ago

Firstly thanks for the wonderful tool.

Requirement: I want to use umockdev for mocking USB device and want inputs on how to do that. I don't have the physical device (it is client owned lab device), but I have the communication requests and responses which the device sends and expect. Below is the illustration image

also to mention recording the device commands is complicated process (multiple approvals and environment issues). I have to create a virtual device(software mock of actual device) for E2E testing.

Please let me know if this is possible(and how) using umockdev . TIA

benzea commented 2 years ago

Well, two general approaches:

  1. You create a full model of the device in software
  2. You do a single recording and assume that your driver always emits the same sequence of commands

Seems like you are going for option 1. Option 2 is obviously much simpler, but requires re-generating the recording when something changes (e.g. libfprint uses this, but doing a recording of a fingerprint device is very simple and quick).

You can do it with umockdev, but it isn't the most convenient. For an example, maybe see the libusb tests which are written in C and have custom handling of URB submission and reaping (you can use any other programming language if you prefer). Have a look specifically at handle_ioctl_cb. As I said, it is not exactly nice to work with, but the API gives you full control of the URBs and how they are reaped.

The main caveat might be that libusb will busy loop, always thinking it can reap an URB. But that is unlikely to be a big issue in a test environment.

I suspect there are other options to do all this, and I really have no idea whether umockdev is the best tool in your case.

benzea commented 2 years ago

Well, I am saying "any other programming language". I haven't actually tried it, I hope it works, but there might be weird things happening when accessing the binary buffers within the IoctlData structure, I suppose.

siddharthshankarpaul commented 2 years ago

Well, two general approaches:

  1. You create a full model of the device in software
  2. You do a single recording and assume that your driver always emits the same sequence of commands

Seems like you are going for option 1. Option 2 is obviously much simpler, but requires re-generating the recording when something changes (e.g. libfprint uses this, but doing a recording of a fingerprint device is very simple and quick).

You can do it with umockdev, but it isn't the most convenient. For an example, maybe see the libusb tests which are written in C and have custom handling of URB submission and reaping (you can use any other programming language if you prefer). Have a look specifically at handle_ioctl_cb. As I said, it is not exactly nice to work with, but the API gives you full control of the URBs and how they are reaped.

The main caveat might be that libusb will busy loop, always thinking it can reap an URB. But that is unlikely to be a big issue in a test environment.

I suspect there are other options to do all this, and I really have no idea whether umockdev is the best tool in your case.

Thanks for the inputs. I am going through the tests and will get back if needed.