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

feat: Add unit tests for BTCHeaderHashBytes and BTCHeaderBytes types #39

Merged
merged 3 commits into from
Jun 29, 2022

Conversation

vitsalis
Copy link
Member

Some basic unit tests.

@vitsalis vitsalis requested a review from aakoshh June 29, 2022 13:44
s.Require().NoError(err, d.name)
s.Require().Equal(d.b, bz, d.name)
s.Require().Equal(len(d.b), size, d.name)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

It's every so slightly confusing that there's a validation during Unmarshal that the header must be 80 bytes long, yet here we assert that it can be instantiated to be shorter. I suppose that's the way it is with the simple byte wrapper that doesn't need a constructor function.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep. The main thing that this function tests is that the marshal method just copies the bytes. It does not perform any checks

Copy link
Contributor

@aakoshh aakoshh left a comment

Choose a reason for hiding this comment

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

Great, glad to see some tests being committed!

I have to admit I didn't read every test carefully, there were too many 😵
That's a lot of testing for something that just unmarshals hex 😅

This would be a great use case for fuzz testing, to avoid hardcoding just a few examples and repeating them for different scenarios. I would probably have just a generator for valid and invalid cases, with a starter corpus of what good looks like, and then do multiple assertions in the same test, to keep it short.

For generating valid data, we could actually generate the wire header struct, where we see what we are doing, and then turn it into bytes and parse that. That kind of random header generator can be reused in many ways later.

@vitsalis
Copy link
Member Author

Thanks! Yep, some fuzz tests would be useful in this case, although I'm not entirely sure how we would generate valid hex headers and hashes. Will check out how we can accomplish that and come back with a new PR that amends to the tests and removes unnecessary stuff.

@vitsalis vitsalis merged commit e99dd64 into main Jun 29, 2022
@vitsalis vitsalis deleted the btclightclient-unit-tests branch June 29, 2022 16:09
@aakoshh
Copy link
Contributor

aakoshh commented Jun 30, 2022

although I'm not entirely sure how we would generate valid hex headers and hashes

Good question, that's why I suggested that you could use the 3rd party library to generate the header struct, just fill it with random data (e.g. a random 32 byte hash for the parent, some random hash for the PoW) and let it do the serialization to bytes.

Then, once your header is marshalled to JSON, you could use a regex to check if it looks like a hex, and that it's 160 characters long.

For unmarshalling, maybe you can use the bytes passed to the fuzz test as a seed for a random generator, generate 160 random hexadecimal characters, then parse them. Random hashes can be generated the same way, just 64 characters.

The regex and the character based generator is there to make sure that you don't end up copy pasting your logic of generating a hex from bytes from your actual code, that you are testing against some other logic.

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.

2 participants