Testing

How Tinkerbus is tested, including the reference downloads that fix the device load plans.

Go tests

go test ./... runs the tests of all packages. Most packages have unit tests next to the code (*_test.go): the protocol frames, datapoint types, project reading, editing and saving, group address exchange, parameter handling, the routing calculation and the send gate.

Test data lives in the repository:

  • internal/project/testdata/ has plain.knxproj and protected.knxproj with the sources and a build script.
  • internal/knxprod/testdata/ has sample.knxprod and dummy.knxprod with their sources and build scripts.
  • internal/download/testdata/ has about 35 capture fixtures.

Reference downloads

The device load plans are tested against recorded reference downloads. A fixture is a text file of what a download sent to a device: load control, property and memory writes, function property commands and the restart, in the format knxcap -fixture prints. The tests (capture_*_test.go) build the plan for the same device and settings and require that it equals the fixture, step by step and octet by octet. There is one family of tests per mask: capture_test.go (0x0021), capture_m112_test.go (0x0705), capture_sysb_test.go (0x07B0), capture_router_test.go (0x091A), capture_bcu1_test.go (0x0012) and capture_partial_test.go for partial downloads.

Some of these tests need the private project files the captures were made from. They read the path from environment variables and are skipped when the variables are not set:

VariableUsed for
ETS_TEST_PROJECT, ETS_TEST_PASSWORD_FILETests on a real project: opening, editing, saving, reports
ETS_TEST_ESYLUX_PROJECTThe 0x0012 captures
ETS_TEST_PARTIAL_PROJECTThe partial download captures
ETS_TEST_MASTER_XMLA real knx_master.xml
ETS_TEST_KEEP_OUTPUTKeep the files a saving test produced

Frontend tests

The helper modules in frontend/src have tests (*.test.ts) that use Node’s built-in test runner: the network layout and routing, the place tree, scan comparison, telegram handling and the online catalog. package.json does not define a script to run them yet.

What is not covered

  • There is no continuous integration yet.
  • Hardware behaviour is verified by hand; see verified masks and Status.
  • The interface has not been checked with a screen reader.