Pokrycie kodu

Pozdrawiamy przyjaciół, kolegów i... pingwiny! Dzisiaj porozmawiamy o pokryciu kodu , dowiemy się, co to jest, dlaczego jest potrzebne i jak ulepszyć projekt open source, dostarczając statystyki pokrycia kodu. Artykuł ten stanowi lakoniczną kontynuację poprzedniego o Continuous Integration . Tutaj poznamy kolejną potężną zaletę CI w połączeniu z... a już niedługo dowiemy się z czym! Podkreślę tylko, że nie będzie tu instrukcji jak poprawnie pisać testy dla swoich programów i jak osiągnąć maksymalny możliwy zasięg użyteczny, cały ten grzech pozostanie tylko na Twoich barkach. Więc chodźmy!

Co to jest pokrycie kodu?

Pokrycie kodu to pewna wartość, która pokazuje nam procent kodu źródłowego ukończonego podczas testów. OK, tutaj wszystko wydaje się jasne. Procent pokrycia kodu może wynosić od 0 do 100 i może pojawić się pytanie: czy należy dążyć do maksymalnego procentu CC? Moja odpowiedź brzmi: tak i nie. Dlaczego? Załóżmy, że tworzysz projekt, który będzie używany przez inne projekty, jest on pełen funkcjonalności, a wśród całej tej grozy są gettery i settery, a jest ich całkiem sporo. Omawiając funkcjonalność, nie wszystkie, powiedzmy, gettery zostały uwzględnione, ale wiesz na pewno, że te, które nie zostały uwzględnione, nie są wywoływane w twoim projekcie, ale gettery nie zawsze są pisane „dla siebie”, więc są potrzebne do „ klient". Co robić? Objąć każdy moduł pobierający osobno? To nie będzie skuteczne badanie. Ale jeśli ich nie uwzględnimy, nie osiągniemy maksymalnego procentu CC. Tutaj pojawia się miecz obosieczny.

Dlaczego potrzebujemy pokrycia kodu?

Myślę, że odpowiedź na to pytanie będzie bardzo prosta: każdy kod wymaga przetestowania, aby podczas refaktoryzacji lub dodawania/zmiany funkcjonalności nie pojawiały się „niewidoczne” błędy i można je było śledzić. Nie będziemy przechodzić przez frameworki z punktami przerwania i debugerami i łapać tego okropnego Buga. Życie jest zbyt krótkie. Przykład A więc najciekawsza rzecz. Zadanie jest takie: Wprowadź do naszego projektu open source , o którym pisaliśmy w poprzednim artykule , technologię, która będzie zbierać informacje o CC, gdzieś je przetwarzać i będzie można umieścić te informacje na GitHubie w postaci pliku odznaka np. Cały kod źródłowy zostanie opublikowany na moim GitHubie .

1. Zacznijmy od wybrania wtyczki zbierającej informacje o pokryciu kodu w jeden stos. Ja osobiście wybrałem JaCoCo , które zbiera informacje o pokryciu kodu. Ale są też alternatywy .

   Сайт JaCoCo предлагает нам скачать плагин, но качать мы нечего не будем, ведь мы используем Build System Maven. Заходим в Maven Repository и ищем JaCoCo Plugin. Берем последнюю версию, и вставляем в наш pom.xml зависимость.

   Но через dependencies я делать не рекомендую, ведь есть более хороший, более функциональный альтернативный вариант, и даже не один.

   1. Заходим CodeCov Setup выбираем язык Java и выбираем Using JaCoCo плагин, и ставим по инструкции.

   2. По той же ссылке выбираем Using Maven. Этот вариант будет даже лучше. Cobertura будет извлекать информацию из CI тестов, но увы и тут есть подвох. Все что выше JDK 7 (А на данный момент уже 10 есть) не подойдет. Поэтому мы остановимся на 1 варианте.

   В результате в нашем pom.xml должно было появиться что то вроде того:

   <!-- JaCoCo plugin -->
   <plugin>
       <groupId>org.jacoco</groupId>
       <artifactId>jacoco-maven-plugin</artifactId>
       <version>0.8.1</version>
       <executions>
           <execution>
               <goals>
                   <goal>prepare-agent</goal>
               </goals>
           </execution>
           <execution>
               <id>report</id>
               <phase>test</phase>
               <goals>
                   <goal>report</goal>
               </goals>
           </execution>
       </executions>
   </plugin>

   И в Maven Projects в списке плагинов появится JaCoCo Plugin:

2. Плагин стоит. Все вроде бы замечательно. Но если вы внимательно читали инструкцию по установке JaCoCo podłącz, там было указание, добавить в .travis.yml строчку, отвечающую за отправку отчёта podłącz на сайт Codecov.

   Итак, исходя из Using JaCoCo, нам нужно вписать в наш файл:

   after_success:
     - bash <(curl -s https://codecov.io/bash)

   Вписали. Отлично.

3. Все вроде готово, и остались финальные штрихи. Во-первых давайте скомпLubруем наш kod, и запустим все тесты, причем сделаем это через Lifecycle Maven:

   Так Jak у нас в плагине JaCoCo стоит фаза выполнения test, то должен был появится отчет после выполнения цикла тестов Maven в папке target:

4. Подходим к завершению. Мы видим что все работает прекрасно, осталось лишь убедится что это "все прекрасно" также будет работать на внешних источниках. Настала пора собрать все в кучу. Собираем проект и делаем push на GitHub, перед этим открыв Travis CI и Codecov для мониторинга происходящего.

   После push мы видим что сборка успешная:

   И результат JaCoCo podłącz о покрытии kodа:

5. Помните нашу задачу? Да, да, мы забыл про бейджик. Я хотел вынести тему "Украшение" open-source project'ов в отдельную статью, но маленькую часть все же оставлю здесь.

   Итак, пошаговая инструкция что бы не заблудится:

   1. Переходим на сайт Codecov;

   2. Выбираем проект, который вам нужно;

   3. Выбираем Setting:

   4. Выбираем Badge и видим ссылки на ваш бейджик в несколько различных формах представления:

      Первые это стандартные бейджики, их можно вставить, например, в ваш README.md:

      Их особенность в том что при кликании на них вас будет перенаправлять на strona с отчетом о CC;

      Вторые это графы, таблицы и тому подобные штуки:

Полезные ссылки

• Мой тестовый проект, который вы можете скачать, посмотреть, оценить. Все по этой статье находится в branch: JaCoCo;
• Narzędzia do obsługi kodu Java ;
• Alternatywy JaCoCo ;
• Biblioteka JaCoCo ;
• Zależność wtyczki JaCoCo Maven ;
• Samouczek konfiguracji Codecov ;
• Właściwie konfigurowanie samego JaCoCo ;
• Konfiguracja Cobertury ;

• Następny artykuł (Markdown)
• Poprzedni artykuł (Ciągła integracja)

W tekście mogą występować błędy i pominięcia. Dziękuję wszystkim za uwagę!