test: Migrate resource, shamap Beast tests to GTest#7133
test: Migrate resource, shamap Beast tests to GTest#7133marek-foss-neti wants to merge 33 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #7133 +/- ##
=========================================
- Coverage 82.0% 81.9% -0.0%
=========================================
Files 1007 1007
Lines 76854 76854
Branches 8984 8983 -1
=========================================
- Hits 62992 62980 -12
- Misses 13853 13865 +12
Partials 9 9 🚀 New features to boost your workflow:
|
|
This PR has conflicts, please resolve them in order for the PR to be reviewed. |
| BEAST_EXPECT(delta.begin()->first == kH1); | ||
| BEAST_EXPECT(delta.begin()->second.first == nullptr); | ||
| BEAST_EXPECT(delta.begin()->second.second->key() == kH1); | ||
| ASSERT_TRUE(sMap.compare(*map2, delta, 100)); |
There was a problem hiding this comment.
I'd like to know your opinion @a1q123456 on using assertions (ASSERTs) in tests, like for example in this case if delta compare fails then the ASSERT guards that consecutive EXPECTs would not run as they might give misleading results.
In GTests, I see that protocol_autogen uses ASSERTs extensively, but they are also used in basics/mulDiv and json. Do you have a preference of EXPECTs over ASSERTs?
This also relates to that task we talked about, of improving asserts exception handling.
There was a problem hiding this comment.
In my opinion, if the rest of the code needs a condition to be true to make sense (e.g. file.is_opened(); file.read_byte() == 1), then we should use ASSERT_*
There was a problem hiding this comment.
Ok, then it is done this way.
65facf7 to
f6c22cb
Compare
|
All conflicts have been resolved. Assigned reviewers can now start or resume their review. |
|
|
||
| void | ||
| run() override | ||
| run(bool backed) |
There was a problem hiding this comment.
Let's get rid of all run functions. If it requires a parameter like this, we can use testing::WithParamInterface<T> and a parameter generator. See: https://google.github.io/googletest/reference/testing.html#WithParamInterface
There was a problem hiding this comment.
Done, and I tried to make it readable as imho the run functions were more readable.
There was a problem hiding this comment.
Why do you think this is more readable? I don't think I'm able to tell what this method tests from the function name. Also, we're putting test code in a Fixture.
There was a problem hiding this comment.
I agree the fixtures are pointless here. Anyway, the latest changes use TEST_P with a predefined constexpr to make it easier to read and see with the backed/unbacked param. Please check if it looks good to you.
|
This PR has conflicts, please resolve them in order for the PR to be reviewed. |
…ration-gtest-resource-shamap # Conflicts: # src/tests/libxrpl/CMakeLists.txt
|
All conflicts have been resolved. Assigned reviewers can now start or resume their review. |
|
This PR has conflicts, please resolve them in order for the PR to be reviewed. |
…ration-gtest-resource-shamap # Conflicts: # .github/scripts/levelization/results/ordering.txt # src/tests/libxrpl/shamap/common.h
|
All conflicts have been resolved. Assigned reviewers can now start or resume their review. |
|
|
||
| do | ||
| { | ||
| f.clock().advance(std::chrono::seconds(1)); |
|
|
||
| sMap.dump(); | ||
| { | ||
| constexpr std::array kEYS{ |
godexsoft
left a comment
There was a problem hiding this comment.
Leaving some improvement ideas. Overall it looks good as a migration 👍
| #include <cstdint> | ||
| #include <string> | ||
|
|
||
| namespace xrpl::Resource { |
There was a problem hiding this comment.
Same question about renaming CamelCase namespaces if that's not too much work. If it is then we can follow up with clang-tidy PR for all of them at once later on.
| Consumer c(logic.newInboundEndpoint(addr)); | ||
|
|
||
| // Create load until we get a warning | ||
| int n = 10000; |
There was a problem hiding this comment.
We try to use auto more. These could definitely be auto and get the exact same types for free.
| bool readmitted = false; | ||
| { | ||
| using namespace std::chrono_literals; | ||
| // Give Consumer time to become readmitted. Should never |
There was a problem hiding this comment.
These comments could probably fit one line now? Or split each sentence per line
| Charge const fee(1000); | ||
| JLOG(j_.info()) << "Charging " << c.toString() << " " << fee << " per second"; | ||
| c.charge(fee); | ||
| for (int i = 0; i < 128; ++i) |
There was a problem hiding this comment.
Let's try to use std::size_t when we do loops as a rule of thumb.
|
|
||
| namespace xrpl::tests { | ||
|
|
||
| #ifndef __INTELLISENSE__ |
There was a problem hiding this comment.
I wonder why this is needed? Is it some old hack required long ago that got migrated over or is this still an issue today?
| { | ||
| constexpr std::array kEYS{ | ||
| uint256( | ||
| "b92891fe4ef6cee585fdc6fda1e09eb4d386363158ec3321b8123e" |
There was a problem hiding this comment.
Oh yikes. Do you think we can somehow make them fit on one line each? Possibly by specifying std::array above or something? not a huge deal but could be better 🥇
| "5a772c6ca8"), | ||
| uint256( | ||
| "292891fe4ef6cee585fdc6fda1e09eb4d386363158ec3321b8123e" | ||
| "5a772c6ca8")}; |
There was a problem hiding this comment.
We also usually add a trailing comma to init lists.
| map.invariants(); | ||
| } | ||
|
|
||
| int h = 7; |
There was a problem hiding this comment.
Would be good to know what this magic number is.. or compute it from map perhaps.
| uint256 rootHash; | ||
| std::vector<Blob> goodPath; | ||
|
|
||
| for (unsigned char c = 1; c < 100; ++c) |
There was a problem hiding this comment.
Can we extract 100 magic number and use it here and to compute 99 and 1 below?
| for (int i = 0; i < items; ++i) | ||
| { | ||
| source.addItem(SHAMapNodeType::TnAccountState, makeRandomAS()); | ||
| if (i % 100 == 0) |
There was a problem hiding this comment.
More magic numbers here and below that could be extracted to make things clearer.
High Level Overview of Change
This change migrates all resource and shamap unit tests from Beast framework to GTest, including the use of the common TestSink from helpers.
Context of Change
The goal is to gradually migrate all Beast tests to GTest.
Type of Change
test:- This change only affects unit tests.API Impact
No impact.
Test Plan
Verification is done by running the automated unit test suite.