You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the "expectations" list for I2C/SPI bus mocks assert an absolute ordering. This is overly restrictive in some cases and locks the test to the process implementation rather than allowing the actual driver requirements to be encoded
Example
An I2C device initialisation that I have goes something like this
a wakeup/unlock sequence (fixed order)
transfer of configuration (a number of registers in any order)
a sleep/lock sequence (fixed order)
With the current crate version, I'm pretty sure my test would have to encode a fixed ordering of operations for that second step. Allowing an unordered set of transactions to occur instead would be beneficial to encode what I actually want to test
The text was updated successfully, but these errors were encountered:
A minor extension of this would be to allow ordered subsequences as well. if the expectations looked something like the following, the init sequence above could be expressed as 3 subsequences and you could probably reuse subsequences more easily (e.g. the "unlock" subsequence gets used a few times. Would be nice to just make a function that returned it)
Currently the "expectations" list for I2C/SPI bus mocks assert an absolute ordering. This is overly restrictive in some cases and locks the test to the process implementation rather than allowing the actual driver requirements to be encoded
Example
An I2C device initialisation that I have goes something like this
With the current crate version, I'm pretty sure my test would have to encode a fixed ordering of operations for that second step. Allowing an unordered set of transactions to occur instead would be beneficial to encode what I actually want to test
The text was updated successfully, but these errors were encountered: