Fail testu w PhpUnit w wypadku warninga

0

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

Kopiuj

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ł?

0

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

0

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.

0

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

0

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:

Kopiuj

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

0

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:
Kopiuj
<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.

Kopiuj

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.

0

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.

0

--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

0

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.

0

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?

0

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ą.

0

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