Closed Shahroz16 closed 10 months ago
Pull request title looks good 👍!
If this pull request gets merged, it will cause a new release of the software. Example: If this project's latest release version is 1.0.0
. If this pull request gets merged in, the next release of this project will be 1.0.1
. This pull request is not a breaking change.
All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time.
Merging #251 (80abdd7) into main (2d32664) will increase coverage by
0.03%
. Report is 2 commits behind head on main. The diff coverage is97.56%
.
@@ Coverage Diff @@
## main #251 +/- ##
============================================
+ Coverage 50.80% 50.84% +0.03%
Complexity 249 249
============================================
Files 108 108
Lines 2781 2779 -2
Branches 364 361 -3
============================================
Hits 1413 1413
+ Misses 1250 1249 -1
+ Partials 118 117 -1
Files Changed | Coverage Δ | |
---|---|---|
...main/java/io/customer/sdk/queue/QueueRunRequest.kt | 98.00% <97.56%> (+7.61%) |
:arrow_up: |
Build available to test
Version: shahroz-fix-bq-outofstack-SNAPSHOT
Repository: https://s01.oss.sonatype.org/content/repositories/snapshots/
@levibostian Thanks for looking into it,
GitHub annotations highlights a couple places where there is code that does not get executed by tests (meaning possible missing tests)
The only highlight seems towards log
statements it seems.
This is a critical part of the code base, execution of the BQ. I strongly suggest that more tests are written for this run function to cover all the possible edge cases.
Can you explain what specific tests are you looking for? I have added some more but asking because we didn't change any logic except move from recursion to iterative approach. So, what gave you confidence in the previous implementation with the current test suite, but now makes you feel less confident?
@Shahroz16 Great questions.
The latest test that you added for when a task cannot be found in storage was 1 missing test case. That's a great test case to add, thank you.
Github annotations is telling me that there is 1 more missing branch for this conditional statement. Adding a test for that scenario would be great.
You do have a good point in that this is a refactor so existing tests should be all that we need. In my original comment I could have explained better that even though this is a refactor, I don't want to ship this code until the test suite is improved upon. If there are missing tests, I wanted to make sure that we add tests to the existing suite to feel more confident in the code.
I recently found a missing test case in this exact same code block in the iOS SDK. When I added the missing test case, I actually found a bug. This makes me want to double check our test suite around this code in the Android SDK to make sure we trust it. I believe this PR is a good opportunity to do that.
I reviewed the current test suite and it looks good to me except:
QueueIntegrationTests
- could we add a test to reproduce this stackoverflow error? Then make sure that this refactor fixes the issue? @levibostian added more tests.
Regarding,
could we add a test to reproduce this stackoverflow error? Then make sure that this refactor fixes the issue?
I did try, but wasn't able to do it because it depends on multiple factors like heap size and limiting it isn't that straight forward with unit tests.
Tests are great! Thanks!
Oh, I just realized there is 1 more conversation to have resolved. I do consider this a blocker for merging this PR.
@levibostian just noticed my comment to it was never posted so did it again, it says 2 days ago
for me that's why I originally added it. Just making sure, you can see it now.
closes: https://github.com/customerio/customerio-android/issues/248