Как Вы измеряете качество своих модульных тестов?
В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.
При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.
Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».
Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример:
public class Some {
private int id;
public int getId(){
return this.id;
}
public setId( int newId ) {
this.id = newId;
}
}
И в другом месте вашего кода:
Some reference = new Some(); // Point to a new object of type Some()
Some otherReference = null; // Initiallly this points to NULL
reference.setId( 1 ); // Execute setId method, now private var id is 1
System.out.println( reference.getId() ); // Prints 1 to the console
otherReference = reference // Now they both point to the only object.
reference = null; // "reference" now point to null.
// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );
// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...
Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.
11 ответов
Моя подсказка не является способом определить, есть ли у Вас хорошие модульные тесты по сути, но это - способ выращивать хороший набор тестов со временем.
Каждый раз, когда Вы встречаетесь с ошибкой, или в Вашей разработке или сообщили кем-то еще, зафиксируйте ее дважды. Вы сначала создаете модульный тест, который воспроизводит проблему. Когда у Вас есть провальный тест, тогда Вы идете и решаете проблему.
, Если проблема была там во-первых, это - подсказка о тонкости о коде или домене. Добавление теста для него позволяет Вам удостовериться, что это никогда не будет повторно представленным в будущем.
Другой интересный аспект об этом подходе - то, что он поможет Вам понять проблему от более высокого уровня, прежде чем Вы на самом деле пойдете и посмотрите на запутанность кода.
кроме того, +1 для значения и ловушек тестового покрытия уже упоминается другими.
Покрытие кода является полезной метрикой, но должно использоваться тщательно. Некоторые люди берут покрытие кода, особенно покрытый процент, немного слишком серьезно и рассматривают его как метрику для хорошего поблочного тестирования.
Мой опыт говорит мне, что более важный, чем попытка получить 100%-е покрытие, которое не настолько легко, люди должны сфокусироваться на проверке, что критические разделы покрыты. Но даже тогда можно получить ложные положительные стороны.
Я - в значительной степени про-TDD, но я не помещаю много важности в статистику покрытия. Мне, успеху и полноценности модульных тестов чувствуется в течение времени разработки группой разработчиков, поскольку тесты (a) раскрывают ошибки впереди, (b) позволяют осуществить рефакторинг и изменение без регрессии, (c) помогают изложить в деталях модульный, разъединенный дизайн, (d) и этажерка.
Или, как Martin Fowler выразился, неподтвержденная информация в поддержку модульных тестов и TDD является подавляющей, но Вы не можете измерить производительность. Читайте больше на его bliki здесь: http://www.martinfowler.com/bliki/CannotMeasureProductivity.html
Если это может повредиться, это должно быть протестировано. Если это может быть протестировано, это должно быть автоматизировано.
Для достижения полной меры уверенности в коде, Вам нужны разные уровни тестирования: единица, интеграция и функциональный. Я соглашаюсь с советом, данным выше этого, указывает, что тестирование должно быть автоматизировано (непрерывная интеграция) и что поблочное тестирование должно покрыть все ответвления множеством наборов данных пограничного случая. Инструменты покрытия кода (например, Cobertura, Клевер, EMMA и т.д.) могут определить дыры в Ваших ответвлениях, но не в качестве Ваших тестовых наборов данных. Статический анализ кода, такой как FindBugs, PMD, CPD может определить проблемные области в Вашем коде, прежде чем они будут становиться проблемой и иметь большое значение для продвижения лучших методов разработки.
Тестирование должно попытаться копировать полную среду, в которой будет работать приложение как можно больше. Это должно начать с самого простого случая (единица) к (функциональному) самому сложному. В случае веб-приложения, заставляя автоматизированный процесс пробежать все варианты использования Вашего веб-сайта со множеством браузеров необходимость так, что-то как SeleniumRC должно быть в Вашем инструментарии.
Однако программное обеспечение существует для встречи бизнес-потребности, таким образом, там также тестирует против требований. Это имеет тенденцию быть большим количеством ручного процесса на основе функциональных (веб-) тестов. По существу необходимо будет создать матрицу трассируемости против каждого требования в спецификации и соответствующем функциональном испытании. Поскольку функциональные испытания создаются, они подходятся против одного или нескольких требований (например, Вход в систему как Fred, обновите банковские реквизиты для пароля, выйдите из системы снова). Это решает проблему того, соответствует ли поставляемый компонент потребностям бизнеса.
В целом, я защитил бы подход разработки через тестирование на основе некоторого аромата автоматизированного поблочного тестирования (JUnit, nUnit и т.д.). Для интеграционного тестирования я рекомендовал бы иметь тестовую базу данных, которая автоматически заполняется в каждой сборке с известным набором данных, который иллюстрирует случаи общего использования, но позволяет, чтобы другие тесты основывались. Для функционального тестирования Вам будет нужен некоторый робот пользовательского интерфейса (SeleniumRC для сети, Аббат для Swing и т.д.). Метрики о каждом могут легко быть собраны во время процесса сборки и отображены на сервере CI (например, Гудзон) для всех разработчиков для наблюдения.
Если Вашим основным способом измерить тестовое качество является некоторая автоматизированная метрика, Вы уже перестали работать.
Метрики могут вводить в заблуждение, и они могут играться. И если метрика будет основным устройством (или хуже уже, только) средства оценки качества, то они будут играться (возможно, неумышленно).
покрытие Кода, например, глубоко вводит в заблуждение, потому что 100%-е покрытие кода нигде не является близким полным тестовым покрытием. Кроме того, число как "80%-е покрытие кода" столь же вводит в заблуждение без контекста. Если то покрытие находится в самых сложных битах кода и просто пропускает код, который так прост, легко проверить глазом тогда, это значительно лучше, чем если бы то покрытие смещается обратным способом.
кроме того, важно различать тестовый домен теста (это - набор функций, по существу), и его качество. Тестовое качество не определяется тем, сколько оно тестирует так же, как качество кода не определяется подробным перечнем функций. Тестовое качество определяется тем, как хорошо тест делает свое задание в тестировании. Этого на самом деле очень трудно подвести итог в автоматизированной метрике.
В следующий раз Вы идете, чтобы записать модульный тест, попробовать этот эксперимент. Посмотрите, сколько различных путей можно записать ему таким образом, что это имеет то же покрытие кода и тестирует тот же код. Посмотрите, ли его возможное для записи очень плохого теста, который соответствует этим критериям и очень хорошему тесту также. Я думаю, что Вы можете быть удивлены результатами.
В конечном счете нет никакой замены для опыта и суждения. Человеческий глаз, надо надеяться, несколько глаз, должен посмотреть на тестовый код и решить, хорошо ли это или нет.
Я обычно делаю TDD, таким образом, я пишу тесты сначала, который помогает мне видеть, как я хочу быть в состоянии использовать объекты.
Затем когда я пишу классы, по большей части я могу определить распространенные ошибки (т.е. предположения, что я делаю, например, переменное, являющееся конкретного типа или диапазон значений), и когда они подходят, я пишу определенный тест для того конкретного случая.
Кроме этого и получения столь же хорошего максимально покрытие кода (иногда не возможно получить 100%), Вы более или менее сделаны. Затем если какие-либо ошибки действительно подходят в будущем, Вы просто удостоверяетесь, что пишете тестовый сценарий для него, который представляет его сначала и передаст, когда зафиксировано. Тогда зафиксируйте согласно нормальному.
Покрытие кода к тестированию, как тестирование к программированию. Это может только сказать Вам, когда существует проблема, это не может сказать Вам, когда все работает. У Вас должно быть 100%-е покрытие кода и вне. Ответвления логики кода должны быть протестированы с несколькими входными значениями, полностью тренируясь нормальный, край и угловые случаи.
Контроль уровней покрытия кода может быть полезным, но вместо того, чтобы фокусироваться на произвольном целевом уровне (80%, 90%, 100%?) Я нашел полезным стремиться к положительной тенденции со временем.
Я думаю, что некоторые лучшие практики для модульных тестов:
- Они должны быть автономными, т.е. не потребовать, чтобы слишком много конфигурации и внешних зависимостей работали. Позвольте тестам создать свои собственные зависимости как файлы и веб-сайты, требуемые для тестов работать.
- модульные тесты Использования для репродуцирования ошибок прежде, чем зафиксировать их. Это помогает препятствовать тому, чтобы ошибки появились снова в будущем.
- Использование инструмент покрытия кода для определения критического кода, который не осуществлен никакими модульными тестами.
- Интегрируют модульные тесты с ночными сборками и сборками конечных версий.
- Публикуют отчеты о результате испытаний и кодируют отчеты о покрытии веб-сайту, где все в команде могут просмотреть их. Публикация должна идеально быть автоматизирована и интегрирована в систему сборки.
не ожидают достигать 100%-го покрытия кода, если Вы не разрабатываете программное обеспечение в жестком реальном времени. Это может быть очень дорогостоящим для достижения этого уровня, и будет для большинства проектов не стоить усилия.
Дополнительная техника, которую я пытаюсь использовать, должна разделить Ваш код в две части. Я недавно вел блог об этом здесь . Краткое описание должно поддержать Ваш производственный код в двух наборах библиотек, где один набор (надо надеяться, больший набор) имеет 100%-е покрытие строки (или лучше если можно измерить его), и другой набор (надо надеяться, крошечный объем кода) имеет 0%-е покрытие, да нулевой процент покрытие.
Ваши проекты должны позволить это разделение. Это должно облегчить видеть код, который не покрыт. Со временем у Вас могут быть идеи о том, как переместить код от меньшего набора до большего набора.