Closed jamesadevine closed 3 years ago
Correct these 3 items could be separated out in 3 workitems, which we want eventually.
I've started on a UI for running a compliance test suite on a module (e.g. https://microsoft.github.io/jacdac-ts/services/button/test/), we need to discuss a strategy here. I think it will be a mix of manual tests ("click on the button now") and possibly automated tests (set a register, see that it changed...). We should be able to extend the markdown to include a test suite.
We should split this into 3 issues.
There are three points at which we need to test and assess quality:
1) Testing the operation of the physical layer/module at the factory.
2) Obtaining QoS information at runtime when in the hands of users.
3) Testing the compliance of services against the specification.
From the call yesterday we decided we need to think about all of these things, but especially 2. It was proposed that we should put some QoS information in advertisement packets, such as a single by that represents the number of packets sent over the previous 500 ms. This byte is optional and is not required to be implemented in all devices, but it would become part of software libraries like jacdac-c.