Testing
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/hasplain.knxprojandprotected.knxprojwith the sources and a build script.internal/knxprod/testdata/hassample.knxprodanddummy.knxprodwith 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:
| Variable | Used for |
|---|---|
ETS_TEST_PROJECT, ETS_TEST_PASSWORD_FILE | Tests on a real project: opening, editing, saving, reports |
ETS_TEST_ESYLUX_PROJECT | The 0x0012 captures |
ETS_TEST_PARTIAL_PROJECT | The partial download captures |
ETS_TEST_MASTER_XML | A real knx_master.xml |
ETS_TEST_KEEP_OUTPUT | Keep 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.