-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Support backward iteration in the RocksDB #1492
Changes from 4 commits
aabe700
60d8e61
31e1136
622cfcf
803b2e8
e243d1b
e48679f
ef6cfc6
8ef0bf0
fa7eea0
fc176b5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -381,7 +381,7 @@ async fn get_transactions() { | |
} | ||
|
||
#[tokio::test] | ||
async fn get_transactions_by_owner_forward_and_backward_iterations() { | ||
async fn get_transactions_by_owner_forward() { | ||
let alice = Address::from([1; 32]); | ||
let bob = Address::from([2; 32]); | ||
|
||
|
@@ -413,17 +413,6 @@ async fn get_transactions_by_owner_forward_and_backward_iterations() { | |
.collect_vec(); | ||
assert_eq!(transactions_forward.len(), 5); | ||
|
||
let all_transactions_backward = PaginationRequest { | ||
cursor: None, | ||
results: 10, | ||
direction: PageDirection::Backward, | ||
}; | ||
let response = client | ||
.transactions_by_owner(&bob, all_transactions_backward) | ||
.await; | ||
// Backward request is not supported right now. | ||
assert!(response.is_err()); | ||
|
||
///////////////// Iteration | ||
|
||
let forward_iter_three = PaginationRequest { | ||
|
@@ -475,6 +464,99 @@ async fn get_transactions_by_owner_forward_and_backward_iterations() { | |
); | ||
} | ||
|
||
#[tokio::test] | ||
async fn get_transactions_by_owner_backward_iterations() { | ||
let alice = Address::from([1; 32]); | ||
let bob = Address::from([2; 32]); | ||
|
||
let mut context = TestContext::new(100).await; | ||
let _ = context.transfer(alice, bob, 1).await.unwrap(); | ||
let _ = context.transfer(alice, bob, 2).await.unwrap(); | ||
let _ = context.transfer(alice, bob, 3).await.unwrap(); | ||
let _ = context.transfer(alice, bob, 4).await.unwrap(); | ||
let _ = context.transfer(alice, bob, 5).await.unwrap(); | ||
|
||
let client = context.client; | ||
|
||
let all_transactions_backward = PaginationRequest { | ||
cursor: None, | ||
results: 10, | ||
direction: PageDirection::Backward, | ||
}; | ||
let response = client | ||
.transactions_by_owner(&bob, all_transactions_backward) | ||
.await | ||
.unwrap(); | ||
let transactions_backward = response | ||
.results | ||
.into_iter() | ||
.map(|tx| { | ||
assert!(matches!(tx.status, TransactionStatus::Success { .. })); | ||
tx.transaction | ||
}) | ||
.collect_vec(); | ||
assert_eq!(transactions_backward.len(), 5); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This looks like you're testing that the request returns paginated data with the correct length. After this, you test that the request returns paginated data with the expected results. Lastly, you test that the request returns paginated data with the expected results when using a cursor. Therefore, I think this test could be broken up into two or three separate tests, since these are three separate concerns. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Splitting this text into three doesn't make much sense because the third test will be almost the same except for two asserts. It increases the test file size and makes it harder to navigate by adding a very slight improvement to the one test readability. I agree that we need to try to test different things with different tests, but when one test is the copy of another + one new line, it is not very nice. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is my opinion on testing, with a bias from working in TDD: Each unit test should illustrate the conformance of a single, functional behaviour (a unit). The behaviour being tested should be described succinctly by the test name. The test suite creates a specification that outlines the complete behaviour of the subject under test, and this specification acts as a promise to the developers using the code: The test names tell us what it will do and the test body proves that it does it. A well-written test suite can serve as living documentation for the code. It clearly demonstrates the intended use cases and the expected behaviour of the software. E.g., Therefore, the goal isn't simply readability, and the fact that test code is duplicated is not really that important. What's more important is that the test suite communicates the intended behaviour succinctly, and test names are the easiest way to achieve that. When I read the test mod, or run all the tests, I can simply look at the list of test names to have an overall sense of what the behaviours are. If that resonates with you, feel free to update the test suite. If not, no worries - again, this is just my opinion. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
|
||
///////////////// Iteration | ||
|
||
let backward_iter_three = PaginationRequest { | ||
cursor: None, | ||
results: 3, | ||
direction: PageDirection::Backward, | ||
}; | ||
let response_after_iter_three = client | ||
.transactions_by_owner(&bob, backward_iter_three) | ||
.await | ||
.unwrap(); | ||
let transactions_backward_iter_three = response_after_iter_three | ||
.results | ||
.into_iter() | ||
.map(|tx| { | ||
assert!(matches!(tx.status, TransactionStatus::Success { .. })); | ||
tx.transaction | ||
}) | ||
.collect_vec(); | ||
assert_eq!(transactions_backward_iter_three.len(), 3); | ||
assert_eq!( | ||
transactions_backward_iter_three[0], | ||
transactions_backward[0] | ||
); | ||
assert_eq!( | ||
transactions_backward_iter_three[1], | ||
transactions_backward[1] | ||
); | ||
assert_eq!( | ||
transactions_backward_iter_three[2], | ||
transactions_backward[2] | ||
); | ||
|
||
let backward_iter_next_two = PaginationRequest { | ||
cursor: response_after_iter_three.cursor.clone(), | ||
results: 2, | ||
direction: PageDirection::Backward, | ||
}; | ||
let response = client | ||
.transactions_by_owner(&bob, backward_iter_next_two) | ||
.await | ||
.unwrap(); | ||
let transactions_backward_iter_next_two = response | ||
.results | ||
.into_iter() | ||
.map(|tx| { | ||
assert!(matches!(tx.status, TransactionStatus::Success { .. })); | ||
tx.transaction | ||
}) | ||
.collect_vec(); | ||
assert_eq!( | ||
transactions_backward_iter_next_two[0], | ||
transactions_backward[3] | ||
); | ||
assert_eq!( | ||
transactions_backward_iter_next_two[1], | ||
transactions_backward[4] | ||
); | ||
} | ||
|
||
#[tokio::test] | ||
async fn get_transactions_from_manual_blocks() { | ||
let (executor, db) = get_executor_and_db(); | ||
|
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 feel like this section could be a little easier to read.
Something like:
Then inside the new
reverse_prefix_iter
, instead of returning early, just do something like:Of course, breaking those down into into smaller functions wouldn't hurt either, but those are the changes that would improve readability the most.