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

Tweak Blocks Generator + Moar Tests + Better Coverage #50

Merged
merged 2 commits into from
Mar 12, 2019

Conversation

KtorZ
Copy link
Member

@KtorZ KtorZ commented Mar 12, 2019

Issue Number

#3

Overview

  • I have increased the number of property being tested
  • I have added coverage checks to our properties
  • I have tweaked a bit the arbitrary generator to not generate empty lists that often

Comments

By looking at the code coverage reports, I noticed that some parts of the code were left
untested, which was weird because they should be when looking at the property.
Yet, I noticed we use 'Int' (n <- arbitrary) as the number of blocks to generate. Int
is unsigned and therefore, doing 'take n' with n < 0 boils down to doing 'take 0'. As
a consequence, our generators was very often generating empty list of blocks, and, in
the remaining cases, didn't always generate sequences of blocks that would trigger
certain parts of the tickingFunction. That is now fixed, and coverage constraints has
been added to make sure of that:

  Block syncer downloads blocks properly
    Check ticking function when blocks are sent
      +++ OK, passed 200 tests (96.0% Non empty blocks).

By looking at the code coverage reports, I noticed that some parts of the code were left
untested, which was weird because they should be part be when looking at the propery.
Yet, I noticed we use 'Int' (n <- arbitrary) as the number of blocks to generate. Int
is unsigned and therefore, doing 'take n' with n < 0 boils down to doing 'take 0'. As
a consequence, our generators was very often generating empty list of blocks, and, in
the remaining cases, didn't always generate sequences of blocks that would trigger
certain parts of the tickingFunction. That is now fixed, and coverage constraints has
been added to make sure of that
@KtorZ KtorZ self-assigned this Mar 12, 2019
@@ -114,7 +117,7 @@ newtype Blocks = Blocks [[Block]]
instance Arbitrary Blocks where
-- No Shrinking
arbitrary = do
n <- arbitrary
n <- fromIntegral . (`mod` 42) <$> arbitrary @Word8
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why 42 here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To have a hard max bound. It's not more useful to generate list of 255 blocks than 42 blocks in practice. We aren't benchmarking anything here, so, we want the list to be big enough to generate enough entropy in the blocks groups, but not too big to not take 5 minutes to run.

42 turned out to be a good enough value :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds reasonable. thanks for the explanation 👍

Copy link
Contributor

@paweljakubas paweljakubas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addressing vulnerable part of block generation and delivering better coverage. LGTM!

@KtorZ KtorZ merged commit eb3a993 into master Mar 12, 2019
@KtorZ KtorZ deleted the KtorZ/#3/blocksyncer-coverage branch March 12, 2019 10:20
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

Successfully merging this pull request may close these issues.

None yet

2 participants