-
-
Notifications
You must be signed in to change notification settings - Fork 599
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
Emulate devices for testing #2258
Comments
@billiaz @ahochsteger Any interest? This would need both some backend work and a nice UI. |
See zwave-js/zwave-js-server#171 for context. I'd like to add more test coverage to |
@raman325 my idea was that you can use the driver with a mocked serialport, like I do for end-to-end tests and send it the serial data that is received by devices. An example can be found here: https://github.com/zwave-js/node-zwave-js/blob/master/packages/zwave-js/src/lib/test/driver/receiveApplicationCommandHandlerBridge.test.ts Enabling this will require a bit of work because right now that setup does not allow you to start from cache without passing in all capabilities by hand or replaying the interview. Basically the necessary steps would then be:
|
that's helpful, thanks! Full disclosure, I have been using this project to learn TypeScript, and tests are something I haven't worked with yet. Everything you said makes sense, next step for me is to figure out how to implement it 🙂 |
The tricky part is here: node-zwave-js/packages/zwave-js/src/lib/driver/Driver.ts Lines 853 to 863 in 68294d7
skips the entire communication with the controller during unit tests. However that call is also responsible for populating the value DB from cache etc, so it will need to be refactored a bit. |
This is actually supported since v10 and actively used in some integration tests I couldn't have done without it. |
It would be helpful for testing downstream for the node to emulate various device classes and allow sending values through the actual library, including things like central scene notifications, basic sets, etc. Alarm values for devices would also be useful (door, water, etc.). This will lessen the need for actual devices to test downstream changes and ease development.
It would also be helpful for an automated pattern to also be able to be run, so that downstream can run automated tests against the emulated devices.
Ideally we would eventually emulate actual devices using data captured from the device, but as an initial step there should at least be a way to setup basic emulated devices of each class and to push through expected types of messages.
@raman325 - Anything to add?
The text was updated successfully, but these errors were encountered: