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

BFT: Block deliverer integration test style #4724

Open
tock-ibm opened this issue Mar 6, 2024 · 0 comments
Open

BFT: Block deliverer integration test style #4724

tock-ibm opened this issue Mar 6, 2024 · 0 comments

Comments

@tock-ibm
Copy link
Contributor

tock-ibm commented Mar 6, 2024

          This style of controlling the mock will only cover one use case.

We want to achieve the same goal with a more flexible API on the mock, not by setting a single private field mo.censorDataMode.

I am thinking about the following:

on every mock you can have the following functions:

// will deliver either data/headers until this point "n" and will then wait for further instructions but NOT break the delivery loop. If a subsequent call DeliverUntil(n2 uint64) (n2>n) the mock will continue to deliver until n2.
DeliverUntil(number uint64)

// answers true if the mock was last requested to deliver data
IsDataDeliverer() bool

// answers true if the mock was last requested to deliver headers
IsHeaderDeliverer() bool

// stops the delivery of blocks but does not stop the mock server.
// If the mock was instructed to deliver until n=5, it will wait there, and then only when instructed to stop, it will exit the loop
StopDelivery()

With this, the "block censorship" test case can then be implemented by:

  1. mark all mocks by DeliverUntil(5)
  2. discover who IsDataDeliverer and who are IsHeaderDeliverer (with eventually)
  3. let the header deliverers continue until the end by marking them DeliverUntil(11)
  4. etc...

I hope you see how this style will allow us to test many more test cases with ease.

The "normal" case is just

  1. mark all mocks by DeliverUntil(11)
  2. etc...

PS - this refactoring can be done in a separate PR. Let's finish the important stuff first (Block censorship detected, etc) and do this after this PR is merged.

Originally posted by @tock-ibm in #4673 (comment)

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