phpunit Tests versursachen Warnungen

[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 nicht 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.

[nelarsen]

Wenn niemand mehr weiß, was "testCustomRecurrence" testet, oder es mit entsprechenden Kommentaren im Quelltext erklären kann: Wollen wir den Test nicht einfach löschen? Mit so einem Test kann man doch nicht arbeiten.

[datengraben]

@nelarsen @hansmorb ich habe mir die WP Cron-API angeschaut und die Tests angepasst, es sollte jetzt keine race condtion im Test mehr den Testerfolg bedingen.

An sich testen wir damit ob die Scheduler Klasse die Cron jobs korrekt anlegt, vor allem die übergebenen Attribute korrekt setzt. Die Werte der Klassen-Attribute (vor allem den timestamp wert) könnten wir aber auch ohne wp_next_scheduled prüfen.

Von mir aus können wir es jetzt schließen.

[hansmorb]

Sind aber auch wieder einige Warnungen, aber vielleicht sollten wir dafür nochmal eine neue issue aufmachen.