Emulate devices for testing

[blhoward2]

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?

[blhoward2]

@billiaz @ahochsteger Any interest? This would need both some backend work and a nice UI.

[raman325]

See zwave-js/zwave-js-server#171 for context. I'd like to add more test coverage to zwave-js-server (we have basically nothing now) so we need test data to work with. If zwave-js provides the data, presumably we can use that to build these tests

[AlCalzone]

@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:

• Create a driver instance with a mock serialport ✔
• Initialize that driver instance with a test network (one cached node) 🛠
• Send the driver data, handle/test events on your end ✔

[raman325]

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 🙂

[AlCalzone]

The tricky part is here:

node-zwave-js/packages/zwave-js/src/lib/driver/Driver.ts

Lines 853 to 863 in 68294d7

	if (!this.options.skipInterview) {
	// Interview the controller.
	await this._controller.interview(initValueDBs, async () => {
	// Try to restore the network information from the cache
	if (process.env.NO_CACHE !== "true") {
	await this.restoreNetworkStructureFromCache();
	}
	});
	// No need to initialize databases if skipInterview is true, because it is only used in some
	// Driver unit tests that don't need access to them
	}

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.

[AlCalzone]

This is actually supported since v10 and actively used in some integration tests I couldn't have done without it.