Ability to replace the DateTimeImmutable class on mocked datetime

[demyan112rv]

pdo-event-store/src/Projection/PdoEventStoreProjector.php

Line 805 in 66d11ab

$now = new DateTimeImmutable('now', new DateTimeZone('UTC'));

This discussion was started in Gitter and continues in this issue.

Demyanovsky Ruslan @demyan112rv 12:40
Hi, tell me please, is there any way to change the datetime in the prooph?
I tried to use Carbon (http://carbon.nesbot.com/docs/#api-testing) but I ran into the problem of redefining time. For instance \Prooph\EventStore\Pdo\Projection\PdoEventStoreProjector::persist() use DateTimeImmutable and i can not replace this class to Carbon class from the outside.

Max Voloshin @max-voloshin 13:02
In several places now is not hardcoded in Prooph, for example in \ Prooph \ Common \ Messaging \ DomainMessage :: init and\ Prooph \ Common \ Messaging \ FQCNMessageFactory :: createMessageFromArray. It will be great to have a similar ability in \ Prooph \ EventStore \ Pdo \ Projection \ PdoEventStoreProjector,\ Prooph \ EventStore \ Pdo \ Projection \ PdoEventStoreReadModelProjector, \ Prooph \ Snapshotter \ SnapshotReadModel :: persist and other places.

Max Voloshin @max-voloshin 13:52
In short: we want to have an end to end tests with an ability to "travel to future" in middle of them.
An idea: pass env variable with desired time to application and observe its state at that time.

[demyan112rv]

At the moment we came to the conclusion that we can use another solution for this case - php-timecop

But I think that it would be good if there was an opportunity to change used classes or to set datetime value from the outside.

[prolic]

In the pdo-event-store-projector there are several places like: acquireLock, updateLock, persist where "NOW" is hardcoded. All those methods are private, so you are unable to inject anything to it.

I can't see any benefit to allow changing the used class name (f.e. to Carbon). Being able to change those values from the outside is a really bad idea IMHO, as it would poise the interface with optional arguments, that you are not supposed to pass in. The only place where you would be interested in this is during unit or integration tests, not for real production usage.

So my advice would be:

1. Leave the pdo-event-store as is, do not change anything (for above mentioned reasons)
2. For testing: Create a SQL QUERY and update the underlying database manually and the change values to whatever you want to. Just be sure, that you may not be possible to switch the event-store implementation without breaking your tests then.

[max-voloshyn]

@prolic thank you for feedback. For now, we are OK with https://github.com/hnw/php-timecop for testing purpose so you may close this issue.