Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sub-sequences that don't require any ordering #53

Open
Crzyrndm opened this issue Jan 3, 2023 · 1 comment
Open

Sub-sequences that don't require any ordering #53

Crzyrndm opened this issue Jan 3, 2023 · 1 comment

Comments

@Crzyrndm
Copy link

Crzyrndm commented Jan 3, 2023

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

  1. a wakeup/unlock sequence (fixed order)
  2. transfer of configuration (a number of registers in any order)
  3. 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

@Crzyrndm
Copy link
Author

Crzyrndm commented Jan 3, 2023

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)

enum I2COps {
  Read (...),
  Write (...),
  WriteRead (...),
  UnOrderedSubSequence ( Vec<Self> ),
  OrderedSubSequence ( Vec<Self> )
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant