2012-08-02 25 views
14

Czy ktoś zna metodę generowania raportów pokrycia z testów PHPSpec?PHPSpec i raport pokrycia

Myślałem o xdebug, ale o ile wiem, nie mogę generować raportów dla jenkins.

Odpowiedz

38

W obecnej wersji (1.4.0) nie obsługuje jeszcze pokrycia kodu. Chętnie usłyszę Twoją opinię na ten temat. Poniżej moja opinia na temat zasięgu kodu.

PHPSpec to framework BDD. Jeśli robiłeś BDD, opisałbyś zachowanie swojej klasy przed napisaniem swojej klasy. Jeśli zrobiłeś to w ten sposób, odpowiednie zachowanie twoich klas byłoby odpowiednio pokryte "testami".

Narzędzia i dane dotyczące zasięgu kodu są przydatne w przypadku starszego kodu (kodu napisanego bez specyfikacji/testów). Możesz użyć takiego narzędzia, aby spróbować osiągnąć punkt, w którym możesz kontynuować TDD i czerpać korzyści z ochrony przed regresją.

Ogólnie rzecz biorąc to podejście nie jest tak skuteczne, jak opisanie zachowania jako pierwszego (TDD). Pojedyncza metoda może być wystarczająco prosta, aby odpowiedzieć na więcej niż jedno wymagane zachowanie. Wiesz, że podczas TDDing, kontynuujesz refaktoryzację, usuwając niepotrzebny kod. Kończy się 10 specyfikacjami (testami) trafiającymi w te same linie kodu, wszystkie opisują różne potrzebne zachowania, a wszystko to jest użyteczne dla zrozumienia kodu.

Jednym z problemów ze słowem "test" jest to, że ludzie myślą, że TDD dotyczy weryfikacji. To nie jest. Chodzi o komunikację. StoryBDD to komunikacja między interesariuszami a SpecBDD to komunikacja między klasami. Prosta, żywa, wystarczająca dokumentacja.

Objęcie kodu w celu zagwarantowania, że ​​przetestowano kod, jest błędne, w najlepszym wypadku kiepskie. Niestety ludzie sądzą, że struktura testowania jest ważniejsza niż testowanie zachowań. Właśnie dlatego narodził się BDD, aby pomóc skupić się na właściwej ścieżce. Upewnienie się, że ta część kodu jest testowana jest fałszywe, ponieważ ta część kodu może zrobić więcej niż jedną rzecz, powinna, jeśli jest ładnie refaktoryzowana. Również skończy się testowanie rzeczy, takich jak akcesory i modyfikatory i konstruktorów, itp.

Ale jestem otwarty, aby usłyszeć społeczność na ten temat. Widzę, że zasięg kodu może być przydatny. Plus od Sebastian Bergmann ładnie modularyzowany z PHPUnit mogę go ponownie użyć w PHPSpec. Wolałbym, żebyś najpierw napisał swoje specyfikacje. Otrzymasz 100% pokrycia kodu swojego właściwego zachowania za darmo. Moim zdaniem, to właśnie ma znaczenie.

+1

Twoje podejście jako bardziej doświadczonej osoby jest dla mnie bardzo cenne.Zaczynam włączać BDD do mojego zespołu, dlatego tak bardzo dbam o robienie tego dobrze i zbieranie przydatnych statystyk :) – spamec

+0

To świetne podejście do nowych projektów, ale co z tego, czy chcemy wdrożyć BDD w istniejącej już starej wersji? Czy masz jakieś doświadczenie w tym? Czy jest jakiś sens, aby napisać Spec dla istniejącego kodu? Moim zdaniem dla starego kodu powinny być testy jednostkowe dla nowej specyfikacji. –

+1

Świetna odpowiedź Marcello. Mimo to, zasięg kodu daje gwarancję, wiara tam, gdzie jej brakuje :) –

6

Myślę, że generator pokrycia kodu byłby przydatny dla starszych systemów, które są w trakcie poddawania testom BDD, ponieważ będziesz w stanie stwierdzić, który kod nie jest testowany. Byłbym wdzięczny za taką funkcję w PHPSpec.

8

Użyj Code Coverage extension to PHPSpec do generowania koniczyny.

Jeśli chcesz połączyć dane pokrycia z PHPSpec i innych narzędzi (np.) PHPUnit, użyj formatu wyjściowego PHP_CodeCoverage z narzędziem phpcov w trybie scalania.

Przykłady:

# phpspec.yml 
extensions: 
    - PhpSpec\Extension\CodeCoverageExtension 

code_coverage: 
    output: /tmp/coverage/phpspec.phpcoverage 
    format: php 

# phpunit.xml 
<logging> 
    <log type="coverage-php" target="/tmp/coverage/phpunit.phpcoverage" /> 
</logging> 

# from the command line 
phpcov merge --clover coverage.xml /tmp/coverage 

To daje zasięg z obu narzędzi w ostatecznej formie koniczyny, odpowiednie dla jak Jenkins.