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

Add unit test for get_counts RPC method (RIPD-1399) #2011

Closed
wants to merge 4 commits into from

Conversation

Projects
None yet
5 participants
@mellery451
Copy link
Contributor

mellery451 commented Feb 10, 2017

No description provided.

@codecov-io

This comment has been minimized.

Copy link

codecov-io commented Feb 10, 2017

Codecov Report

Merging #2011 into develop will increase coverage by 0.29%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop    #2011      +/-   ##
===========================================
+ Coverage    67.25%   67.54%   +0.29%     
===========================================
  Files          683      683              
  Lines        49231    49231              
===========================================
+ Hits         33111    33255     +144     
+ Misses       16120    15976     -144
Impacted Files Coverage Δ
src/ripple/app/ledger/PendingSaves.h 93.54% <0%> (-6.46%)
src/ripple/basics/impl/make_SSLContext.cpp 52.22% <0%> (-1.28%)
src/ripple/app/misc/NetworkOPs.cpp 62.56% <0%> (+0.15%)
src/ripple/app/ledger/impl/LedgerMaster.cpp 44.64% <0%> (+0.22%)
src/ripple/app/main/Application.cpp 60.63% <0%> (+0.26%)
src/ripple/protocol/STObject.h 91.56% <0%> (+0.42%)
src/ripple/net/impl/RPCCall.cpp 36.15% <0%> (+0.82%)
src/ripple/basics/TaggedCache.h 79.42% <0%> (+2.28%)
src/ripple/app/ledger/impl/InboundLedgers.cpp 27.81% <0%> (+2.36%)
src/ripple/protocol/STArray.h 87.8% <0%> (+2.43%)
... and 17 more

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 0b605b3...914616f. Read the comment docs.

@bachase
Copy link
Contributor

bachase left a comment

👍

BEAST_EXPECT(jrr[jss::status] == "success");
BEAST_EXPECT(! jrr.isMember("Transaction"));
BEAST_EXPECT(! jrr.isMember("STObject"));
BEAST_EXPECT(! jrr.isMember("HashRouterEntry"));

This comment has been minimized.

Copy link
@bachase

bachase Feb 14, 2017

Contributor

How did you decide which fields to look for?

This comment has been minimized.

Copy link
@mellery451

mellery451 Feb 14, 2017

Author Contributor

I looked for counted objects in the subsequent request (after there are some actual counts reported) and then just verified that those same fields are not present in this initial request. This is definitely not exhaustive and probably could be improved.

This comment has been minimized.

Copy link
@bachase

bachase Feb 14, 2017

Contributor

Seems reasonable to me since the RPC doesn't guarantee much.

BEAST_EXPECT(jrr[jss::status] == "success");
BEAST_EXPECT(
jrr.isMember("Transaction") &&
jrr["Transaction"].asInt() > 0);

This comment has been minimized.

Copy link
@scottschurr

scottschurr Feb 15, 2017

Contributor

I'm a little surprised that you're using > 0 comparisons. Since you have complete control of the environment shouldn't most of these values be repeatable? I'm just surprised, not necessarily objecting.

This comment has been minimized.

Copy link
@mellery451

mellery451 Feb 15, 2017

Author Contributor

These are "counted objects" which I didn't feel I had direct enough control over to warrant an exact check. That said, I can very likely access the CountedObjects singleton and validate directly -- do you think that would worthwhile?

This comment has been minimized.

Copy link
@scottschurr

scottschurr Feb 15, 2017

Contributor

Hmmm. I'm a little surprised that you don't think the CountedObjects are predicable enough to give reliable results. But I've never looked at them very hard. I certainly accept your assessment.

Interesting thought about comparing to the CountedObject values. It would not be worth heroic efforts to have an exact value to compare against. But if it's relatively easy to do it might be nice. Your call.

@scottschurr
Copy link
Contributor

scottschurr left a comment

What's here looks good to me. 👍

BEAST_EXPECT(jrr[jss::status] == "success");
BEAST_EXPECT(
jrr.isMember("Transaction") &&
jrr["Transaction"].asInt() > 0);

This comment has been minimized.

Copy link
@scottschurr

scottschurr Feb 15, 2017

Contributor

Hmmm. I'm a little surprised that you don't think the CountedObjects are predicable enough to give reliable results. But I've never looked at them very hard. I certainly accept your assessment.

Interesting thought about comparing to the CountedObject values. It would not be worth heroic efforts to have an exact value to compare against. But if it's relatively easy to do it might be nice. Your call.

@mellery451 mellery451 added the Passed label Feb 16, 2017

@scottschurr

This comment has been minimized.

Copy link
Contributor

scottschurr commented Feb 17, 2017

Nice! Revised tests look even better. 👍

@mellery451 mellery451 force-pushed the mellery451:getcounts branch from 6c0238e to 914616f Mar 1, 2017

@seelabs

This comment has been minimized.

Copy link
Contributor

seelabs commented Mar 1, 2017

In 0.60.0-b7

@seelabs seelabs closed this Mar 1, 2017

@mellery451 mellery451 deleted the mellery451:getcounts branch Mar 1, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.