Fail testu w PhpUnit w wypadku warninga

Zainstalowałem sobie PhpUnit 11, i zauważyłem że warningi nie failują testów.

C:\Users\Riddle\PhpstormProjects\plast> php .\vendor\bin\phpunit test
PHPUnit 11.2.0 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.3.1
Configuration: C:\Users\Riddle\PhpstormProjects\plast\phpunit.xml
Random Seed:   1717935221

..WW                                                                4 / 4 (100%)

Time: 00:00.424, Memory: 30.00 MB

OK, but there were issues!
Tests: 4, Assertions: 4, Warnings: 1.
C:\Users\Riddle\PhpstormProjects\plast>

Mamy green.

Próbowałem odpalać z --fail-on-warning oraz ustawiająć failOnWarning="true" w phpunit.xml, ale to nic nie daje.

Jak zrobię --display-warnings, to widzę ten warning, ale chcę żeby test sfailował.

Ktoś ma pomysł?

a próbowałeś z convertWarningsToExceptions?

https://stackoverflow.com/questions/28767578/how-to-make-php-warnings-fail-phpunit-test-cases:

convertWarningsToExceptions refers to PHP warnings (emitted with something like trigger_error('warning', E_USER_WARNING);) and failOnWarning refers to PHPUnit warnings

Raczej powinno być to ustawione w xml jak opisane:
failOnWarning="true". Może nie czyta Ci tego XMLa w ogóle? Zmień na próbę coś typu kolorowanie błędów.
Z 11 nic nie robiłem.

jurek1980 napisał(a):

Raczej powinno być to ustawione w xml jak opisane:
failOnWarning="true". Może nie czyta Ci tego XMLa w ogóle? Zmień na próbę coś typu kolorowanie błędów.
Z 11 nic nie robiłem.

Sprawdziłem to, i czyta plik - ustawiłem np losową kolejność testów jak i nazwę pliku cache, i te zmiany są brane pod uwagę.

obscurity napisał(a):

a próbowałeś z convertWarningsToExceptions?

Dziękuję za tę super bezcenną podpowiedź, ale ta opcja została usunięta jeszcze w PhpUnit 10.

https://github.com/sebastianbergmann/phpunit/blob/10.0.0/ChangeLog-10.0.md#removed

Nie mam teraz możliwości testu, ale wrzuciłem z ciekawości pytanie w GPT i wypluło, że w 11 jest zmiana i powinno być coś takiego:

<failOn>
    <warning/>
</failOn>

Nie wiem skąd to sobie wziął, bo dokumentacja ciągle mówi o innych ustawieniach, przynajmniej ta, którą czytałem.
Jak masz chęć spróbuj. Nie mogę znaleźć źródła potwierdzającego takie zmiany.

jurek1980 napisał(a):

Nie mam teraz możliwości testu, ale wrzuciłem z ciekawości pytanie w GPT i wypluło, że w 11 jest zmiana i powinno być coś takiego:

<failOn>
    <warning/>
</failOn>

Nie wiem skąd to sobie wziął, bo dokumentacja ciągle mówi o innych ustawieniach, przynajmniej ta, którą czytałem.
Jak masz chęć spróbuj. Nie mogę znaleźć źródła potwierdzającego takie zmiany.

Czy bardzo proszę, mógłbyś nie wrzucać nieprawdziwych informacji? Nie ma takiej flagi.

Time: 00:00.700, Memory: 32.00 MB

There was 1 PHPUnit test runner warning:

1) Test results may not be as expected because the XML configuration file did not pass validation:

  Line 9:
  - Element 'failOn': This element is not expected.


WARNINGS!
Tests: 6, Assertions: 6, Warnings: 2.

Jak widać na powyższym, GPT to nie lekarstwo na wszystko i ciągle człowiek czytający dokumentację jest potrzebny. Nie wprowadzałem w błąd celowo, pisałem jasno, że to kod wypluty. Spróbuję może wieczorem sam zrobić test na środowisku u siebie.

--fail-on-warning działa zgodnie z opisem w dokumentacji https://docs.phpunit.de/en/11.2/textui.html#exit-with-error-code-when

Exit with a shell exit code that signals failure even when all tests passed but at least one test triggered a warning.

Czyli zmienia się kod zwracany przez proces PHP, ale nie ma to wpływu na treść komunikatu podsumowującego testy. Więc jeśli np. testy będą wpięte w jakiś pipeline to będzie fail, bo runner sprawdza exit code procesu a nie treść komunikatu. Ale wizualnie różnicy nie widać. Chyba, że ktoś ma np. prompt w shellu ustawiony na podświetlanie komend zwracających niezerowy exit code.

A komunikat nie zmienia się dlatego, że PHPUnit ściśle rozgranicza Outcome od Issues https://docs.phpunit.de/en/11.2/textui.html#outcome-and-issues

Pafnucy napisał(a):

A komunikat nie zmienia się dlatego, że PHPUnit ściśle rozgranicza Outcome od Issues https://docs.phpunit.de/en/11.2/textui.html#outcome-and-issues

Bardzo dobrze, że są odgraniczone.

Teraz - jak skonfigurować tak żeby każdy Issue był outcomem, który failuje test?

Pafnucy napisał(a):

Czyli zmienia się kod zwracany przez proces PHP, ale nie ma to wpływu na treść komunikatu podsumowującego testy. Więc jeśli np. testy będą wpięte w jakiś pipeline to będzie fail, bo runner sprawdza exit code procesu a nie treść komunikatu. Ale wizualnie różnicy nie widać. Chyba, że ktoś ma np. prompt w shellu ustawiony na podświetlanie komend zwracających niezerowy exit code.

No dobrze, ale to w żaden sposób nie pomaga podczas developmentu - ja potrzebuje wiedzieć który dokładnie test wygenerował ten warning, dlatego chcę żeby jeden konkretny test sfailował.

Fail w runnerze w pipeline to i tak jest za późno, ja chcę to widzieć na maszynie developerskiej, tak samo jak fail każdego innego testu. Dlatego chciałem żeby warning był failem.

Teraz - jak skonfigurować tak żeby każdy Issue był outcomem, który failuje test?

Nie mam pojęcia moim zdaniem byłoby to niemądre.

Fail w runnerze w pipeline to i tak jest za późno, ja chcę to widzieć na maszynie developerskiej, tak samo jak fail każdego innego testu.

Jak dla mnie --fail-on-warning połączone z --display-warnings jest wystarczające do lokalnego developmentu. Trochę nie rozumiem, czego tu brakuje.

Mój lokalny development to:
a) albo PHPStorm, w którym testy sfailują przy takiej konfiguracji (nie wiem, czy IDE od razu przeskoczy do odpowiedniego testu, ale przypuszczam, że tak),
b) albo uruchamianie testów z CLI, gdzie mam prompt ustawiony tak, że zmienia kolor jeśli exit code procesu jest niezerowy, więc dzięki --fail-on-warning widzę, że coś "świeci się na czerwono", a dzięki --display-warnings widzę, w którym to pliku.

Może dorzuć jeszcze --stop-on-warning aby zatrzymał się na pierwszym warningu zamiast lecieć dalej?

Pafnucy napisał(a):

Mój lokalny development to:
a) albo PHPStorm, w którym testy sfailują przy takiej konfiguracji (nie wiem, czy IDE od razu przeskoczy do odpowiedniego testu, ale przypuszczam, że tak),

No ale własnie nie failują. One przechodzą z tym warningiem. O to właśnie chodzi, że ja chcę żeby failowały.

Odpal sobie PhpUnit 11, otwórz PHP storm, wywołaj jakiś warning (np zdefiniuj stałą dwa razy), i zobaczysz że wszystkie testy przejdą. PhpUnit to wykryje, bo napisze "warnings: 1", ale testy przejdą. Nic się nie pokaże na czerwono. Możesz dopisać --fail-on-warning oraz --display-warning, ale to nadal nie sprawia że testy failują.

Ja bym chciał że jak mam warning, to testy failują.

Riddle napisał(a):

Pafnucy napisał(a):

Mój lokalny development to:
a) albo PHPStorm, w którym testy sfailują przy takiej konfiguracji (nie wiem, czy IDE od razu przeskoczy do odpowiedniego testu, ale przypuszczam, że tak),

No ale własnie nie failują. One przechodzą z tym warningiem. O to właśnie chodzi, że ja chcę żeby failowały.

Odpal sobie PhpUnit 11, otwórz PHP storm, wywołaj jakiś warning (np zdefiniuj stałą dwa razy), i zobaczysz że wszystkie testy przejdą.

A to ciekawostka. Zaczęły przechodzić / przestały failować od jakiejś wersji PHPUnita, bo komuś przeszkadzało, że failowały.
Ma to sens jeśli brać pod uwagę w.w. ścisłą separację Outcomes od Issues.
Konkretnie to zmienił się typ komunikatu w protokole Teamcity wykorzystywanym do komunikacji z PHPStorm: https://github.com/sebastianbergmann/phpunit/pull/4623

To tylko pokazuje wyższość odpalania testów z konsoli nad jakimiś IDE