Adds tests for get_one

[mlodato517]

This PR
Attempting to help along with #31.

Notes
It appeared that get_one wasn't tested. I'm not sure if these tests are in the right place or if they should live in read/mod. Or maybe this isn't tested because it's not valuable functionality? 🤷

I tried to handle both inner cases - ValuesInner::Short and ValuesInner::Long. I'm not 100% sure it's necessary to test ValuesInner::Long because, although it's supported, it's clearly documented that, in the case of multiple values, the exact return value is not guaranteed. So it's nice to make sure it doesn't explode with multiple values but it also doesn't feel particularly useful asserting any particular returned value. I also feel pretty badly about the magic number with no hard-reference to BAG_THRESHOLD. If we do want to improve the readability there, it looked like there was a with_capacity on Options but I didn't see one for evmap so I wasn't sure how to do that idiomatically. I probably read the docs wrong. It looks like you can do something like:

Options::default().with_capacity(BAG_THRESHOLD).construct()

although maybe there's a slightly more compact method.

Finally, I don't know how to check code coverage before merging this so acknowledging that there's no guarantee the coverage will increase, I'm fine with just chucking this PR (but would still like to help if any more specific guidance is available!). Looks like it shows up right there in the PR! Neat!

---

This change is 

[codecov]

Codecov Report

Merging #56 into master will increase coverage by 1.68%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #56      +/-   ##
==========================================
+ Coverage   79.13%   80.82%   +1.68%     
==========================================
  Files          11       11              
  Lines         997     1043      +46     
==========================================
+ Hits          789      843      +54     
+ Misses        208      200       -8     

Impacted Files	Coverage Δ
src/values.rs	89.26% <100.00%> (+8.90%)	⬆️
tests/lib.rs	98.00% <100.00%> (+0.04%)	⬆️
src/read/mod.rs	72.41% <0.00%> (+2.64%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b72919f...c907045. Read the comment docs.

[jonhoo]

This is great, thank you! I left some comments :)

[mlodato517]

Also, slightly unrelated - I see the CI failing scarily (to someone who didn't know why). It seems like the version of evmap in benchmark/Cargo.toml can be updated to the current 11.0.0-alpha.1. Is that something to fix or is that purposefully not being upgraded until a non-alpha/beta/whatever release lands?

[jonhoo]

Oh, yeah, good catch! If you want to include a quick fix for that in this PR too, that'd be great.

[mlodato517]

Oh, yeah, good catch! If you want to include a quick fix for that in this PR too, that'd be great.

Sorry, just saw this. Do you mind if I make it a new PR? I already had a new PR ready to go with the changes and figured it'd keep each PR's focus clean? But I'm also 100% down to combine them to reduce overhead!

I could squash all the existing commits and then add the new commit that bumps the dependency version and not squash those two if you'd prefer 👍

Edit:
That PR is here (but I'm still open to closing it and merging the two!).

[jonhoo]

Beautiful! I merged that PR, and squashed and merged this one. Thanks for all your work on this :D

[mlodato517]

It's been my pleasure! Are there any other tests I should focus on next? Or any other things you've been wanting to get to but haven't had time? I really want to start contributing and learning/writing rust. Seeing as I've already learned a handful of things from this, I'd say continuing on would be fruitful. So I'm ready and rearing for anything you need or know about someone else needing! 👍

[jonhoo]

I think an awesome thing would be to adopt parts of the test suites from hashbrown and indexmap. They have extensive test suites, which evmap could possibly benefit a lot from. You'll have to work around evmap having a slightly different API, but it shouldn't be too bad, at least for the simpler tests. Some quicktests would also be fantastic.