phpunit tests verursachen Warningen

[nelarsen]

Ich erstelle mehrere PR, um Warnungen untern "Run test suite" für PHP Unit Tests los zu werden:

• fix TimeframeTest::testRemoveIrrelevantPostmeta(), update_post_meta was called with object rather than post ID fix testRemoveIrrelevantPostmeta #1608
• fix tests/php/Service/BookingRuleAppliedTest.php & tests/php/Repository/TimeframeTest.php, avoid "Creation of dynamic property" (deprecation from php 8.2) Warnung loswerden: Creation of dynamic property ... is deprecated #1607
• src/Map/SearchShortcode.php change style string interpolation Change deprecated way of string interpolation #1609
• tests/php/View/BookingTest_AJAX_Test.php, fix BookingTest_AJAX_Test that was not cleaning up created BookingCodesTable BookingTest_AJAX_Test: proper cleanup of created database table #1610
• fix BookingCodesMessage::sendMessage() for case when sending of ICal attachment is disabled (default). Then a non-empty (!) array with a single null element was passed to prepareMail(), making the check !empty($attachment) in * SendNotificationMail() return true ("there are attachments" even if there is just a null in an array) and causing warnings due to wrong use of PHPmailer. fix BookingCodesMessage:sendMessage() wrong $attachment for prepareMail #1606
• Der Test CommonsBooking\Tests\Service\SchedulerTest::testCustomRecurrence schlägt manchmal zufällig (laufzeitbedingt) fehl: Failed asserting that 1719824258 matches expected 1719824259. Wenn er fehlschlägt, immer um 1 sekunde.

[hansmorb]

Ja für den letzten weiß ich leider auch keine Lösung. Vielleicht reicht es auch einfach eine Toleranz einzubauen.

[nelarsen]

Ja für den letzten weiß ich leider auch keine Lösung. Vielleicht reicht es auch einfach eine Toleranz einzubauen.

Es ist für mich leider ganz klar, was "testCustomRecurrence" testet oder wie der Scheduler funktioniert. Der Scheduler wird mit einem leeren vierten Parameter, $executionTime aufgerufen, so dass der Constructor von Scheduler das macht: $this->timestamp = time(). Diese Zeit wird dann an wp_schedule_event gefüttert. Die Zeit ist nicht eingefrohren, und kurze Zeit später wird von der Testfunktion geprüft ob die aktuelle Uhrzeit noch gleich wp_next_scheduled() ist?
Wenn bloß das getestet werden soll, könnte man entweder die Zeit einfrieren (wie in anderen Tests?) oder tatsächlich erlauben, dass wp_next_scheduled() bis zu ein paar Sekunden in der Vergangenheit zurückgibt.
Ich traue mir nicht so richtig eine Änderung zu, weil ich nicht verstanden habe, wie der Scheduler und der Test gedacht sind.