-
Notifications
You must be signed in to change notification settings - Fork 355
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
fix: Include time when filtering in tracker exporter [DHIS2-16019] #15474
Conversation
Codecov Report
@@ Coverage Diff @@
## master #15474 +/- ##
============================================
+ Coverage 66.15% 66.21% +0.05%
- Complexity 31176 31213 +37
============================================
Files 3485 3485
Lines 129745 129739 -6
Branches 15134 15134
============================================
+ Hits 85828 85901 +73
+ Misses 36830 36753 -77
+ Partials 7087 7085 -2
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 11 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
throws ForbiddenException, NotFoundException, BadRequestException { | ||
Date oneHourBeforeLastUpdated = | ||
Date.from( | ||
trackedEntityA |
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 am not following how this date is supposed to test all changes we are applying. Can we make a test where we actually have a date match? Or maybe there is and i do not see it
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.
We are just testing that the filter on updatedAt
is working.
We try to get all the TE that were updated in the last hour and we want to assert that they are present.
I am not sure we should assert on the date as the next test is doing the opposite and filter on something that will return no TEs and so there we will not have any date to assert
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.
ok but i am a bit surprised that we made these changes and there are no tests failing. So maybe there is no test coverage or it is not fine-grained to time. I see many where conditions are changed now so maybe we could think of some test coverage for that. But maybe i am wrong
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.
Yeah, you are right.
There are no failures just because this change is not a breaking one, so any case working before is still working but we need to cover more cases.
I am adding the new test cases for all the changes
Kudos, SonarCloud Quality Gate passed! |
No description provided.