Как получить лучшее покрытие кода в Java? - PullRequest
Новая
       10

Как получить лучшее покрытие кода в Java?

0 голосов
/ 18 ноября 2009

Существует несколько инструментов, позволяющих рассчитать покрытие пути для набора тестов, но есть ли инструмент (или алгоритм), который мог бы предложить значения, чтобы получить наилучшее покрытие пути с наименьшим количеством возможных тестов?

Например, со следующими классами: 

public class User {

    private boolean isAdmin = false;
    private String name;
    private String password;

    public User(String name, String password, boolean isAdmin) {
        this.name = name;
        this.password = password;
        this.isAdmin = isAdmin;
    }

    public boolean isAdmin() {
        return isAdmin;
    }

    public boolean authenticate(String name, String password) {
        if (name.equals(this.name) && password.equals(this.password)) {
        return true;
        } else {
            return false;
        }
    }
}

public class DataRepository {

    List<String> data = new ArrayList<String>();

    public void add(String dataPiece) {
        data.add(dataPiece);
    }

    public void clearAll(User userAuthenticated) {
        if (userAuthenticated.isAdmin()) {
            data.clear();
        }
    }

    public void addAll(User userAuthenticated, List<String> collection) {
        if (userAuthenticated.isAdmin()) {
            data.addAll(collection);
        }
    }
}

Я получу лучшее покрытие теста, если создам тест, в котором используется Пользователь с isAdmin при true .

Существует ли инструмент, который мог бы упомянуть: если вы создадите тест с Пользователь с isAdmin при true , вы получите наилучшее покрытие теста.

Нечто подобное, но для более сложных случаев, и это проверяет все ветви кода.

Ответы [ 4 ]

6 голосов
/ 18 ноября 2009

О каких «ценностях» вы говорите, предлагая?

Покрытие кода работает путем проверки того, какие строки / методы / классы и т. Д. Выполняются во время определенного сеанса. Обычно это используется при запуске автоматических модульных тестов, но это не обязательно (например, вы можете настроить веб-приложение перед его развертыванием для тестирования дыма, чтобы получить представление о том, какие пути кода вы не использовали в своих специальных тестах) .

Способ увеличить охват - просто убедиться, что вы вызываете больше методов с аргументами, которые выполняют больше внутренних ветвей, в контексте того, что вы измеряете (например, модульные тесты). Ни один инструмент не скажет вам точно, что написать для этого - они выделяют то, что не было проверено, и вы сами должны написать тест, который это сделает.

Если ваш вопрос не был «какой инструмент покрытия дает самые высокие измерения для покрытия», в этом случае это плохой критерий для оценки пригодности.

РЕДАКТИРОВАТЬ - вы также должны понимать, что цель тестов не состоит в том, чтобы получить хорошие оценки покрытия . Покрытие кода полезно только для того, чтобы показать, какой код определенно не проверен . Класс может по-прежнему иметь 100% покрытие без каких-либо полезных тестов (например, тривиально, те, у которых нет каких-либо утверждений - или, более часто, те, чьи утверждения также проходят для некоторых ошибочных значений).

Таким образом, если вы пишете тесты исключительно с целью увеличения охвата, ваши тесты будут мусором и ничего вам не дадут. Пишите тесты, изначально думая исключительно о функциональности класса, и только когда вы думаете, что я закончил, запустите его через инструмент покрытия. Используйте выходные данные инструмента, чтобы вы могли видеть блоки кода, которые не были выполнены, что может означать, что вам нужно написать больше тестов, проходящих на разных входах. И, прежде всего, при написании тестов всегда будьте уверены в том, что именно вы тестируете, и какие результаты должны быть успешными и неудачными.

5 голосов
/ 18 ноября 2009

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

Многие инструменты могут вычислить цикломатическую сложность функции. Если это значение слишком велико, вы просто не сможете проверить все перестановки функции.

Покрытие кода - это средство, а не цель. Покрытие кода не доказывает правильность кода, а инструмент покрытия полезен только для выявления ошибок, которые он помогает.

3 голосов
/ 18 ноября 2009

Чтобы ответить на ваш вопрос о предложении значений для тестов, вы могли бы взглянуть на Agitar (http://www.agitar.com/).. Я помню, как давал представление об этом много лет назад, и я уверен, что он изменился (надеюсь, к лучшему). ) с тех пор, но это может быть то, что вы ищете. Я сам продолжал бы идти по пути TDD и других вещей, которые я упомянул в моем другом ответе, но если вам интересно, вот небольшая часть о том, что сайт Agitar должен сказать:

"Семейство продуктов AgitarOne помогает вам работать безопаснее, лучше и эффективнее при разработке и обслуживании приложений Java. AgitarOne JUnit Generator создает подробные тесты JUnit для вашего кода. Это помогает вам находить регрессии, а также делает их безопаснее и проще для улучшения Ваш код, чтобы снизить затраты на его обслуживание. "

1 голос
/ 18 ноября 2009

Разработка через тестирование. Если вы хотите получить наилучшее покрытие, вы можете попробовать протестировать весь код, который вы пишете. Это требует большой дисциплины и даже лучше, когда вы создаете пару программ, но если вы сделаете это правильно, я бы ожидал 100% покрытия кода.

Еще один совет - свести к минимуму количество написанных вами модульных тестов, когда вы тестируете один класс атомарно и, таким образом, заглушаете другие классы. Наиболее мощные тесты (например, системные тесты или приемочные тесты или как вы хотите их называть) - это те, которые начинаются как можно выше в цепочке классов (если возможно, прямо в точке входа вашего приложения), а затем тестируются без озвучивания или дразнить что угодно. В худшем случае вы работали бы с полной системой, общаясь только с базой данных в памяти, такой как hsqldb, содержащей ваши тестовые данные. Написание таких тестов поможет сократить количество имеющихся у вас классов тестов (и, следовательно, тестов), а также упростит рефакторинг рабочего кода, а также поддержание этих тестов в будущем по мере добавления новых функций.

...