Coordinator - Extra tests for findConsecutiveProvenBlobs #186
Conversation
bradbown
temporarily deployed
to
docker-build-and-e2e
GitHub Actions
Inactive
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #186 +/- ##
============================================
+ Coverage 70.38% 70.39% +0.01%
Complexity 1040 1040
============================================
Files 282 282
Lines 11314 11314
Branches 1082 1082
============================================
+ Hits 7963 7965 +2
Misses 2880 2880
+ Partials 471 469 -2
*This pull request uses carry forward flags. Click here to find out more. |
| val blobs = listOf(blob1, blob2) | ||
|
|
||
| batches.forEach { insertBatch(it).get() } | ||
| blobs.forEach { insertBlob(it).get() } |
There was a problem hiding this comment.
this is slow. can't they be inserted in parallel ino the Db with SafeFuture.collectAll?
I keep on calling on this :(
| @Test | ||
| fun findConsecutiveProvenBlobsWhenDbIsEmpty() { | ||
| aggregationsPostgresDaoImpl.findConsecutiveProvenBlobs(0).get().also { blobCounters -> | ||
| assertThat(blobCounters).hasSameElementsAs(emptyList()) |
There was a problem hiding this comment.
| assertThat(blobCounters).hasSameElementsAs(emptyList()) | |
| assertThat(blobCounters).isEmpty() |
| } | ||
|
|
||
| @Test | ||
| fun findConsecutiveProvenBlobsUnprovenBlobAndBatchAtDifferentIntervals() { |
There was a problem hiding this comment.
I thought we were not supposed to have unproven records in the DB. Are we trying to represent any real scenario here?
However, if the DAO/db was designed for such scenarios, then it shall test it
| blobs.forEach { insertBlob(it).get() } | ||
|
|
||
| aggregationsPostgresDaoImpl.findConsecutiveProvenBlobs(0).get().also { blobCounters -> | ||
| assertThat(blobCounters).hasSameElementsAs(emptyList()) |
There was a problem hiding this comment.
I still don't understand well what this test is trying to ensure. Can you please explain?
findConsecutiveProvenBlobs(startBlockNumber) is supposed to return result if there is a blob starting at startBlockNumber right? If so, shall we call it with 1 instead and return blob1 [0..20]?
This PR implements issue(s) #
Checklist