-
Notifications
You must be signed in to change notification settings - Fork 7
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
Demo removing signing, message-building and semi-automated delivery own messages #385
Conversation
Implement an emulator to test the core GPBFT protocol, with fine-grained control and assertion over message-by-message progress of a participant. Add utility functions to reduce the boilerplate code during testing and implement state transition tests that assert state transition occurs: * for proposal when there is strong evidence of prepare. * for base when there is no strong support for any proposal * for base by timeout alone for a sole participant. Part of #9
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## masih/emulator-with-simple-test #385 +/- ##
===================================================================
+ Coverage 82.42% 82.63% +0.20%
===================================================================
Files 21 21
Lines 2048 2038 -10
===================================================================
- Hits 1688 1684 -4
- Misses 209 212 +3
+ Partials 151 142 -9
|
b11b000
to
a3215b1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Many thanks for taking the time to put this together. I'll cherry pick things from it onto the original PR 🙏
|
||
// New instantiates a new Emulator with the given GPBFT options. See | ||
// Emulator.Start. | ||
func New(assertions *Assertions, o ...gpbft.Option) *Driver { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May be a YAGNI but the reason i did not do this was to avoid having emulator package depend on testing
. This is so that the emulator can be used at production level code in the future for non-testing scenarios: for example using emulator as a light-weight tool to research core protocol improvements. That would separate the emulated behaviour from what it considers "correct".
If YAGNI, then I would take testing.T
here straight up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would use the simulator for protocol R&D (that's what it was first built for). This is for unit tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are probably right, thanks
proposal := instance.GetProposal() | ||
// TODO: replace verifyBroadcast with VerifyQuality, VerifyPrepare etc that | ||
// have similar inspections to those removed from Assertions | ||
em.VerifyBroadcast(instance.NewQuality(proposal)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This style is much more readable than mine; thanks Alex
aaaa25e
to
b48b568
Compare
Demo some of the things I discussed in #359 to check for myself that they make sense.
Don't merge this PR - take or leave whatever you want from it.