-
Notifications
You must be signed in to change notification settings - Fork 46
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unleash the treefrog #11
Conversation
1e26a4d
to
7ce8cec
Compare
6bdfb2e
to
0e05090
Compare
The `treefrog` module was still using the old name.
0e05090
to
0b5ec22
Compare
948f113
to
093c25a
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.
Code looks good to me! I took the liberty of pushing some additional cargo fmt + travis etc stuff into this PR, plus a rebase or two.
馃憤 |
Do you have merge rights, or should I click the big "merge pull request" button for you? |
I have merge rights; I was going to let travis finish. |
@frankmcsherry btw have you given any thought to how to do automated testing? I was contemplating trying to generate random data and some kind of "mega naive merge" algorithm and use that to create unit tests of the various join combinators. |
Possible mega naive join would be something like:
|
I have given it thought, and not come up with anything especially good. At least, over in more general "differential" space, I've not had great ideas about how to cover the sketchy cases with confidence. What I've done over there is try to do something like Graydon's philosophy that when you land commits you also put in tests that break before but not afterwards. These were more perf-oriented than correctness, though. =/ |
OK. I figured I'd start off with a base of various "smoke tests" that use random data like I suggested, and then we'd add regression tests for specific bugs that are found (as you suggest). |
That seems sane. One should be able to write fuzzing tests with random data, I'd bet, relating e.g. treefrog, naive datafrog, and brute-force, but I'm not sure about the confidence (e.g. would cover random data, but not random queries which are more strongly bound to the code itself). |
Indeed. I opened #15 for further discussion. |
It could be time, for the 馃惛 to leap from its tree and join us.
Worst case, that leap is optimal!
:)