Closed sfirke closed 1 month ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 83.89%. Comparing base (
76d897e
) to head (0bcedac
). Report is 760 commits behind head on master.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@villebro I can mimic those tests for Postgres. Though I wonder about the rigor of comparing the code in my spec to pasting the same code in a test. What if instead/also I had it test the transformation of a specific timestamp? Like that rounding ... 00:15:01
to 1 minute intervals gives ... 00:15:00
etc. Unless that's already happening here and I'm missing it.
@villebro I can mimic those tests for Postgres. Though I wonder about the rigor of comparing the code in my spec to pasting the same code in a test. What if instead/also I had it test the transformation of a specific timestamp? Like that rounding
... 00:15:01
to 1 minute intervals gives... 00:15:00
etc. Unless that's already happening here and I'm missing it.
So the reason why these tests are valuable, despite looking like pure duplication, is because a change might happen that causes these time grain definitions to no longer be used. For example, I once did a big refactor of the db engine specs (#7676), and that refactor caused the time grains to be removed by mistake from the Hive engine spec (this was later fixed in #10084). If we would have had tests like this in place, we would have caught that error during the refactor. I know it may look funny to duplicate that functional logic to the unit tests, but having them there makes it less likely to introduce regressions, and it also makes it safer to refactor the implementation details.
Also one thing to note here, is that the unit test is in fact testing the function BaseEngineSpec.get_timestamp_expr
, which is different from the map _time_grain_expressions
that currently contains the expression definitions. It is highly likely that we will, at some point, change how time grains are defined, without changing the method that's used to retrieve the actual expression. So while they may look highly duplicated, they're actually slightly different.
Regarding actual functional verification that the expression actually rounds down the timestamp based on the time grain, that is something that we can't unfortunately test here, as that logic resides in Postgres. But correct me if I'm misunderstanding what you're saying.
Thank you for that thorough explanation! I now see the point of these tests. And whoops I missed that we can't actually test the output of the time grain because that happens in Postgres, good call. Okay, I will add tests like these.
SUMMARY
I added to the Postgres engine spec definitions for some of the time grains that are defined in the base spec but had not been added to Postgres yet.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
TESTING INSTRUCTIONS
In an ephemeral environment, confirm that the grains are there and that the generated queries are correct.