2010-08-25 13 views
5

Gdy wystąpi błąd, którego nie oczekuje system PHPunit, testowanie zostanie przerwane, a PHP zgłosi błąd, ale program PHPunit nie zarejestruje, że był to błąd. Jak się upewnić, że PHPunit rejestruje to jako błąd.PHPunit - Błędy

+1

Czy możesz rozwinąć to? O jakich błędach mówisz? Jaki jest przewidywany wynik działania phpunit i jaki jest faktyczny wynik? – janmoesen

+0

Więc PHPunit ma Asercje, Niepowodzenia i Błędy z tego, co rozumiem. Powiedzmy, że w kodzie jest błąd składni. Dodatkowy przecinek lub brakujący średnik. Spowoduje to, że pewne testy nie będą mogły być uruchomione, a testowanie zakończy się, ale PHPunit nie zgłosi go jako błędu, a php wyświetli błąd, ale nie ma zapisu tego przez PHPunit. Czy istnieje sposób, aby zmusić PHPunit do logowania czegoś podobnego do błędu składni, a nie tylko do asercji kodu logistycznego? – Anthony

+0

Czy możesz podać ilustrację TestCase do tego proszę (poważnie) – Gordon

Odpowiedz

5

Zrzeczenie się, jestem nowy w PHPUnit i próbuję rozgryźć całość "co się dzieje, gdy wystąpi błąd".

Od PHPUnit's docs:

When the tested code contains PHP syntax errors, the TextUI test runner might exit without printing error information. The standard test suite loader can optionally check the test suite sourcefile for PHP syntax errors, but not sourcefiles included by the test suite sourcefile.

I opcja:

--syntax-check   Try to check source files for syntax errors. 
+0

Zobacz mój ostatni komentarz do pierwotnego pytania. (Domyślnie jest ukryty.) Nie ma błędu składni PHP; tylko błąd składni SQL. – janmoesen

+0

@janmoesen Wiem, ale w komentarzach OP mówi również: "Więc powiedzmy, że w kodzie jest błąd składniowy, dodatkowy przecinek lub brakujący średnik, co spowoduje, że pewien test nie będzie w stanie działać, i testowanie zakończy się, ale PHPunit nie zgłosi go jako błędu, a php wyświetli błąd, ale nie ma tego zapisu przez PHPunit. " –

0

Co PO mówi o jest błąd składni PHP lub zabije PHPUnit. PHP Błędy krytyczne zabijają interpreter PHP (lub powodują jego zatrzymanie co najmniej), co oznacza, że ​​PHPUnit nie może kontynuować.

Jeśli naprawdę chcesz uniknąć tej sytuacji, możesz dodać niektóre z poniższych bitów do skryptu. Ten skrypt zakłada, że ​​skrypt znajduje się w katalogu z twoimi testami (./) i że twoje drzewo kodu zaczyna się od ../ (podobne ustawienia do normalnej konfiguracji ZendFramework 1). Nie przejmuj się używaniem kodu z tym skryptem, będzie to poprawne tylko w przypadku ostatniego uruchomienia unittest:

#!/bin/bash 
    for i in $(find ../ -name "*.php"); do 
     msg=`php -l $i` 
     if [ "$?" != "0" ]; then 
      echo $msg; 
     fi 
    done 

    for i in $(find ./ -name "*Test.php"); do 
    echo "Running Test: $i"; 

    phpunit $i 
    done 

HTH.

0

Będziesz musiał przechwycić błąd za pomocą normalnego przechwytywania błędów PHP, aby uniknąć awarii systemu operacyjnego, co dzieje się, gdy interpreter PHP napotka błąd.

Zautomatyzowane testy należy sprawdzić i przetestować przed zatwierdzeniem do głównego strumienia rozwoju.

Przechwytywam dane wyjściowe z PHPUnit (phpunit ...> PHPUnit.log), które następnie analizuję, szukając statusu z PHPUnit (powodzenie z pominiętymi/niekompletnymi, OK, FAILURE, etc ...) i jeśli to jest nie znaleziono, to wiem, że PHPUnit nie zakończyło się i wystąpił błąd. Wyniki błędu zostaną również zrzucone na terminal, ponieważ mój PHP jest skonfigurowany tak, aby pokazywał błędy.

Po błędzie wysyłam ten plik dziennika do zespołu programistów lub osoby, która ostatnio zmieniła plik testowy, w celu sprawdzenia. Logika do wiadomości e-mail może stać się skomplikowana, jeśli skrypty spróbują określić główną przyczynę/osobę, do której zostanie wysłana wiadomość. Zazwyczaj skrypt przesyła mi e-maile w celu sprawdzenia, a zespół programistów jest w CC'd na e-mailu, na wypadek, gdy jestem nieobecny lub nie mogę go od razu zbadać.