time freezing doesn't work properly with zyte-common-items

[kmike]

I tried to use scrapy-poet's savefixture together with Product item from zyte-common-items. The result:

meta.json:

{
    "frozen_time": "2023-01-31T17:25:54.362413+00:00"
}

output.json:

    "metadata": {
        "dateDownloaded": "2023-01-31T17:25:55Z",
        "probability": 1.0
    },

And then, comparison fails when running pytest, on a freshly generated fixture:

E         -  'metadata': {'dateDownloaded': '2023-01-31T17:25:55Z', 'probability': 1.0},
E         ?                                                    ^
E         +  'metadata': {'dateDownloaded': '2023-01-31T17:25:54Z', 'probability': 1.0},
E         ?                                                    ^

Seems to be some issue with rounding, but I'm not sure; haven't checked it. Another possibile explanation is that without freezing the time during test generation the time can change.

[wRAR]

We should remove fractional seconds from frozen_time. But it's also because the time ticks.

If all time values we use and compare have precision only in seconds, time ticking for less that a second will not cause problems. If a test runs (i.e. the page object generates the item) for longer than 1 second, we need a way to compare values with a margin, as discussed earlier.

[kmike]

If all time values we use and compare have precision only in seconds, time ticking for less that a second will not cause problems.

Wouldn't it be an issue for faster tests if the current time is XX:XX:59.9999, and then time moves forward?

I wonder if we need some weird workaround, e.g. waiting for a minute to start before recording the time :)

[kmike]

What's the workaround for the users if the issue happens (e.g. because extraction takes more than a second)? Is it to change either frozen_time or dateDownloaded manually to make them match?

[wRAR]

Wouldn't it be an issue for faster tests if the current time is XX:XX:59.9999, and then time moves forward?

If frozen_time is XX:XX:59, the "current time" will start at XX:XX:59 (both when generating and when testing), the fractions of a second won't matter. This is because savefixture saves the current time and runs the test generation under time_machine with time set to that value and then exports the same value as frozen_time. We just need to set microseconds of that saved time value to 0.

What's the workaround for the users if the issue happens (e.g. because extraction takes more than a second)? Is it to change either frozen_time or dateDownloaded manually to make them match?

For now? Probably yes, but only if you now that e.g. dateDownloaded is always 1 second later than frozen_time. If it's not that deterministic, I don't see a good workaround.

[kmike]

Partially addressed by scrapinghub/scrapy-poet#122.

[wRAR]

Unfortunately having test generation take more than 1 second is easy, especially with additional requests, when using scrapy-poet for that. Initializing the spider and waiting for the server response, or several responses, can easily take more than 1 second.

Though it's easy to change dateDownloaded in output.json to be equal to frozen_time manually after the test generation.