-
Notifications
You must be signed in to change notification settings - Fork 94
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
Feature/random test output #9
Conversation
When a random test package triggers a unhandled parser exception, the content of this packet as well as the stack trace are printed in order to ease debugging
Are you ok to help maintaining this module? If you are ok with CONTRIBUTING.md, I'll add you to the collaborators. |
|
||
function doParse () { | ||
var parser = mqtt.parser() | ||
parser.on('error', onError) | ||
parser.parse(crypto.randomBytes(Math.floor(Math.random() * 10))) | ||
randomPacket = crypto.randomBytes(Math.floor(Math.random() * 10)) |
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.
Possibly we should generate more longer packets, maybe up to 256 or 512 bytes.
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 also thought we possibly should shape the stochastic distritbution of the first byte so that most packets at least enter the parser and aren't rejected by the first gate (packet type selector)
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.
That make sense as well :).
Sure! |
Feel free to add yourself to the contributors list at the end :). |
- longer chunks are passed into the parser, causing multiple packets parsed from one chunk from time to time - first byte of every chunk is now very likely to be valid, thus more packets actually make it to the deeper parsing routines - more detailed test output
I added everything we talked about and observed a few interesting things:
I would finish and merge this test now. |
How long is now? I've set things up we run this on travis, but if that takes much time we need to short that up / make the number of rounds configurable, so in Travis is small enough. |
All good for me, feel free to merge. |
Duration should be fine for travis. It was more like: increasing packet length from 10 to 512 increased the time from 0.8s to 2.2s. In the first place I thought: wow, why should packet length increase the execution time? But the answer can be seen above. |
Improved algorithm and output for parser tests of random chunks
When a random test package triggers a unhandled parser exception, the
content of this packet as well as the stack trace are printed in order
to ease debugging