Skip to content
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 broken playtime entries test. #2094

Merged
merged 3 commits into from
Oct 2, 2024
Merged

Conversation

dbernstein
Copy link
Contributor

Description

This update fixes a broken test. The test started failing due to a date addition issue that was interacting badly with the current month. I changed it to ensure that the playtime entry in question is always in scope.

Motivation and Context

Build was broken.

How Has This Been Tested?

Checklist

  • I have updated the documentation accordingly.
  • All new and existing tests passed.

Copy link

codecov bot commented Oct 1, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.65%. Comparing base (ebcddca) to head (98e9cda).
Report is 2 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2094   +/-   ##
=======================================
  Coverage   90.65%   90.65%           
=======================================
  Files         344      344           
  Lines       40580    40581    +1     
  Branches     8822     8822           
=======================================
+ Hits        36789    36790    +1     
  Misses       2484     2484           
  Partials     1307     1307           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

playtime(
db.session, identifier, collection, library, dt1m(31), 2, loan_identifier
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this entry is meant to be near the beginning of the month during which the report is being run and, thus, should not be included in the report. dt1m is calculating an offset from the first day of the previous month.

I believe that:

  • the dt1m(31) entry is meant to represent "out of range - after reporting period", and
  • the `dt1m(-31) entry, "out of range - before reporting period" (it is helpfully labeled to that effect)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right I think that test wants to verify that two identifiers on the same library, collection and loan sum the have their seconds summed together. When it was dt1m(31), they were both being summed up to 3 (1+2) because dt1m(31) was in the past. However today is October 1st. dt1m(31) is Sept 1st + 31 days = October 2 in the future.

So the expected values were wrong, but it was also my intent to verify that two invocations with the same parameters at different but value times are summed. I'll update the test.

Copy link
Contributor

@tdilauro tdilauro Oct 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But the defaults for that script are to run the previous month, as indicated by the cutoff and until dates in the test; so no entry from the current month should be counted. The until date is after what should be included in the report.

    cutoff = date1m(0).replace(day=1)
    until = utc_now().date().replace(day=1)

Here's the explanation of the until date from the scripts argparser:

        help="'Until' date for report in ISO 8601 'yyyy-mm-dd' format."
        " The report will represent entries from the 'start' date up until,"
        " but not including, this date.",

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay PR updates. It turns out sqlalchemy's between function is inclusive which is not what we want to align with until definition in the argparser.

I verified that one month back plus 30 days (which is Oct 1st) failed before the change to the where clause. Then it passed with the updates. Then I changed it to 31 so that it will succeed in a 31 day month like October.

…thint a reporting period AND non-counting of invocations in the future.
@dbernstein dbernstein force-pushed the fix-broken-playtime-entries-test branch from e3ee129 to aec4fed Compare October 1, 2024 21:51
@@ -238,7 +238,12 @@ def _fetch_report_records(self, start: datetime, until: datetime) -> Query:
sql_max(coalesce(PlaytimeSummary.title, "")).label("title2"),
count(distinct(PlaytimeSummary.loan_identifier)).label("loan_count"),
)
.where(PlaytimeSummary.timestamp.between(start, until))
.where(
and_(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This where clause is exclusive whereas between is inclusive.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good freakin catch. I don't know how you do it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😊 Thanks!

The tests really caught it. I just noticed that we were needing to relax a test that should've passed.

Copy link
Contributor

@tdilauro tdilauro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! 🎉

I requested change to the comment in the test.

db.session, identifier, collection, library, dt1m(31), 2, loan_identifier
db.session, identifier, collection, library, dt1m(4), 2, loan_identifier
)
# one month + 31 days ago : out of range of reporting period
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor quibble about this comment: it sounds like it's over two months ago. Could we re-word to something like:

# out of range: after end of default reporting period

But, good to have this labeled, so that we know what's up next time! For future us! 🥂

@@ -238,7 +238,12 @@ def _fetch_report_records(self, start: datetime, until: datetime) -> Query:
sql_max(coalesce(PlaytimeSummary.title, "")).label("title2"),
count(distinct(PlaytimeSummary.loan_identifier)).label("loan_count"),
)
.where(PlaytimeSummary.timestamp.between(start, until))
.where(
and_(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😊 Thanks!

The tests really caught it. I just noticed that we were needing to relax a test that should've passed.

@dbernstein dbernstein force-pushed the fix-broken-playtime-entries-test branch from aec4fed to 98e9cda Compare October 2, 2024 15:17
@dbernstein dbernstein merged commit a6a44e2 into main Oct 2, 2024
20 checks passed
@dbernstein dbernstein deleted the fix-broken-playtime-entries-test branch October 2, 2024 15:41
@dbernstein dbernstein added the bug Something isn't working label Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants