Почему должен я и Модульный тест И веб-тест (вместо просто веб-теста)?
Исключение нулевого указателя - это индикатор того, что вы используете объект, не инициализируя его.
Например, ниже - класс ученика, который будет использовать его в нашем коде.
public class Student {
private int id;
public int getId() {
return this.id;
}
public setId(int newId) {
this.id = newId;
}
}
Приведенный ниже код дает вам исключение с нулевым указателем.
public class School {
Student obj_Student;
public School() {
try {
obj_Student.getId();
}
catch(Exception e) {
System.out.println("Null Pointer ");
}
}
}
Поскольку вы используете Obj_Student, но вы забыли инициализировать его, как в правильном коде, показанном ниже:
public class School {
Student obj_Student;
public School() {
try {
obj_Student = new Student();
obj_Student.setId(12);
obj_Student.getId();
}
catch(Exception e) {
System.out.println("Null Pointer ");
}
}
}
12 ответов
покрытие Кода гарантирует, что я удар каждая функциональная часть кода
, "Хит" не делает среднее "Тестирование"
, проблема только с выполнением тестирования сети состоит в том, что это только гарантирует, что Вы совершаете нападки код, и что это появляется , чтобы быть корректным на высоком уровне.
Просто, потому что Вы загрузили страницу, и она не отказала, не означает, что она на самом деле работает правильно. Вот некоторые вещи, с которыми я встретился, где 'веб-тесты' покрыли 100% кода, все же полностью пропустил некоторые очень серьезные ошибки, которые не будет иметь поблочное тестирование.
- страница, загруженная правильно из кэша, но фактической базы данных, была повреждена
- , страница загрузила каждый объект из базы данных, но только отобразила первую - это, казалось, было прекрасно даже при том, что это перестало работать полностью в производстве, потому что это брало слишком долго
- , страница отобразила допустимо выглядящее число, которое было на самом деле неправильным, но это не было взято, потому что 1000000 легко принять за 100 000
- , страница отобразилась, верный номер по совпадению - 10x50 совпадает с 25x20, но каждый НЕПРАВ
- , страница, как предполагалось, добавила запись в журнале к базе данных, но это не видимо пользователю, таким образом, это не было замечено.
- Аутентификация была обойдена, чтобы заставить веб-тесты на самом деле работать, таким образом, мы пропустили явную ошибку в коде аутентификации.
легко придумать сотни большего количества примеров вещей как это.
Вам нужны оба модульных теста, чтобы удостовериться, что Ваш код на самом деле делает то, что он, как предполагается, делает на низком уровне, и затем функциональный / интеграция (который Вы называете сетью), тесты сверху тех, чтобы доказать, что он на самом деле работает, когда все те маленькие unit-tested-pieces объединяются в цепочку вместе.
Поблочное тестирование, вероятно, будет значительно более быстрым в благоприятном повороте, чем веб-тестирование. Это верно не только с точки зрения времени разработки (где можно протестировать метод в изоляции намного более легко, если можно достигнуть его непосредственно, чем если бы необходимо создать особый запрос, который в конечном счете поразит его, несколько слоев позже), но также и во время выполнения (выполняющий тысячи запросов в последовательности займет больше времени, чем выполнение сокращенных методов тысячи времен).
Поблочное тестирование протестирует небольшие единицы функциональности, поэтому когда они перестанут работать, необходимо быть в состоянии изолировать, где проблема очень легко.
, Кроме того, намного легче дразнить зависимости с модульными тестами чем тогда, когда Вы поражаете полный фронтэнд - если я не пропустил что-то, действительно охлаждаются. (Несколько лет назад я смотрел на то, как насмешка и веб-тестирование могла интегрироваться, и в то время, когда не было ничего соответствующего.)
Поблочное тестирование обычно не доказывает, что любой данный набор работ функциональности - по крайней мере, оно, как не предполагается. Оказывается, что Ваши работы по договору класса, поскольку Вы ожидаете его к.
Приемочные испытания более ориентированы в потребительских требованиях. Каждое требование должно иметь приемочное испытание, но нет действительно никакого требования между приемочными испытаниями и модульными тестами - они даже не могли бы быть в той же платформе.
Поблочное тестирование может использоваться для управления разработкой кода, и скорость перетестирования является значимым фактором. При тестировании Вы часто удаляете части, на которые класс под тестом полагается для тестирования в изоляции.
Приемочные испытания система так же, как Вы поставили бы его - от GUI до базы данных. Иногда они занимают часы или дни (или недели) для выполнения.
, Если Вы начинаете думать о нем как два совершенно других зверя, Вы будете намного более эффективным тестером.
Хорошие, сфокусированные unittests делают его намного быстрее, чтобы найти и решить проблемы, когда они неожиданно возникают. Когда правильно написанный unittest повреждается, Вы знаете в значительной степени, что означает отказ и что вызвало его.
кроме того, они обычно быстрее для выполнения, означая, что Вы, намного более вероятно, выполните их во время разработки как часть Вашего цикла испытаний компиляции редактирования (в противоположность только, когда Вы соберетесь регистрация).
Когда Вы запишете модульные тесты, Вы будете вынуждены записать свой код лучшим способом. Более слабо связанный и более объектно-ориентированный. Это приведет к лучшей архитектуре и более гибкой системе.
, Если Вы пишете модульные тесты в стиле TDD, Вы, вероятно, сделаете не, делают столько же ненужного кода, потому что Вы сфокусируетесь на крошечных шагах и только сделаете необходимое.
Вы будете более уверены при выполнении осуществляющий рефакторинг для улучшения кода, чтобы увеличить пригодность для обслуживания и уменьшить запах кода.
И модульный тест самостоятельно будет служить exilent документацией того, что система делает и не делает.
Те - всего несколько примеров преимуществ, которые я заметил при применении TDD к моей работе.
Еще один аспект - прощает несколько идеальную среду, в которой это расположено:
предположим у Вас есть 3 компонента, которые наконец должны сотрудничать. Каждый может индивидуально быть полностью протестирован на единицу (независимо от того, что это означает) с 5 модульными тестами. Это делает 5 + 5 + 5 = 15 модульные тесты на полный обзор.
Теперь, если у Вас есть свой тест интеграции/сети/объединенной, который тестирует все компоненты вместе, Вам было бы нужно (помните идеальный мир за этот абстрактный сценарий) 5 * 5 * 5 = 125 тесты, которые тестируют все перестановки, чтобы дать Вам тот же результат как эти 15 тестовых сценариев выше (учитывая, что можно даже инициировать все перестановки, иначе было бы непротестированное/неуказанное поведение, которое могло бы укусить Вас позже, когда Вы расширяете свои компоненты).
Дополнительно эти 125 тестовых сценариев имели бы значительно более сложную установку, более высокий срок выполнения работы и значительно уменьшенная пригодность для обслуживания должны функция когда-либо изменяться. Я выбрал бы 15 модульных тестов плюс некоторые основные веб-тесты, которые гарантируют, что компоненты соединены проводом несколько правильно.
Поблочное тестирование дает Вам скорость и больше всего, сверхвысокая точность того, где отказ или ошибка были представлены. Это позволяет Вам протестировать каждый компонент, изолированный от любого компонента и быть уверенными, что это работает, как это должно.
, Например, если у Вас был веб-тест, который передал запрос Ajax обратно сервису на сервер, которые тогда поражают базу данных, которая тогда перестала работать. Действительно ли это был JavaScript, сервис, бизнес-логика или база данных, которая вызвала проблему?
, Где, как будто Вы модульный тест каждый сервис самостоятельно, блокируя/дразня базу данных или каждую единицу бизнес-логики, тогда Вы, более вероятно, будете знать точно, где ошибка. Поблочное тестирование меньше о покрытии (хотя важно) и больше об изоляции.
Почти, как Dijkstra выразился: модульные тесты могли только использоваться, чтобы показать, что программное обеспечение имеет дефекты, чтобы не доказать, что это без дефектов. Так, в целом удар каждого пути выполнения кода однажды (и получение 100%-го покрытия) не имеют никакого отношения к тестированию - это просто помогает устранить bitrot.
при игре его книгой каждая серьезная ошибка должна быть устранена только после того, как существует модульный тест, записанный, который инициировал ту ошибку. По совпадению фиксация ошибки означает, что этот конкретный модульный тест не перестал работать больше. В будущем этот модульный тест проверяет, что эта конкретная ошибка остается фиксированной.
намного легче записать модульный тест, который инициировал особую ошибку, чем запись сквозной (веб-) тест, который делает ТОЛЬКО это и не выполняет "кучу" абсолютно несоответствующего кода по пути (который мог также перестать работать и испортить с анализом первопричины).
Тест Модульных тестов, что каждый компонент работает. Они чрезвычайно полезны в нахождении дефектов близко ко времени, они создаются, который существенно сокращает стоимость для фиксации дефектов и существенно сокращает количество дефектов, которые заканчиваются в выпуске. Кроме того, хорошие модульные тесты делают рефакторинг намного легче и более устойчивым.
Интеграционные тесты (или "веб-" тесты в этом случае) также очень важны, но являются более поздней линией обороны, чем модульные тесты. Единственный интеграционный тест покрывает такой огромный ряд кода, что, когда каждый перестал работать, это требует, чтобы большое расследование определило дефект (или возможно группа дефектов), который вызвал отказ. Это является дорогостоящим, особенно когда Вы пытаетесь протестировать сборку конечных версий для получения его снаружи. Это является еще более дорогостоящим, учитывая, что шанс начинания ошибки с фиксацией имеет тенденцию быть довольно высоким в среднем и шанс, что отказ блокирует дальнейшее тестирование выпуска (который является чрезвычайно дорогим к циклу разработки).
Напротив, когда модульный тест перестал работать, Вы знаете точно, где дефектный код, и Вы обычно знаете точно, что код делает неправильно. Кроме того, отказ модульного теста должен только повлиять на одного разработчика за один раз и быть зафиксирован, прежде чем в коде регистрируются.
всегда более дорого исправить ошибки позже, чем ранее. Всегда.
Рассматривают создание автомобиля. Вы ожидали бы до всех списков механизма от сборочного конвейера для тестирования того каждого компонента работы? В той точке, если Вы обнаруживаете, не работают проигрыватель компакт-дисков или механизм или кондиционер или круиз-контроль, необходимо взять целый механизм от строки, решить проблему, затем повторно протестировать все (который, надо надеяться, не показывает новых дефектов). Это - очевидно, неправильный способ сделать это, так же, как, очевидно, неправильно попытаться выпустить программное обеспечение, только тестируя, если это работает в конце процесса, а не на каждом важном шаге вдоль строки с нуля.
Это зависит от как архитектура приложения ASP.NET. Если веб-страницы являются просто присоединением базовый слой бизнес-логики или уровень доступа к данным, то модульные тесты, работающие независимо от модели состояния ASP.NET, быстрее разработчику и выполнению, чем подобные тесты WaitiN.
я недавно разработал область приложения ASP.NET прежней версии, в Visual Studio 2003, с NUnit как среда тестирования. Принимая во внимание, что ранее тестирование включенной работы через тесты UI для обеспечения функциональности было реализовано правильно, 90% тестирования произошли, не требуя взаимодействия UI.
единственной проблемой, которую я имел, были временные оценки - одна из задач была запланирована в Trac как взятие 1 дня для доступа к данным / бизнес-логика, и 2 дня для создания UI и тестирования. С работающим NUnit на основе доступа к данным / бизнес-логика время для той части разработки прошло с 1 дня до 2 дней. Разработка UI была уменьшена до единственного 1/2 дня.
Это продолжило другие задачи в новом модуле, добавляемом к приложению. Модульные тесты обнаружили ошибки быстрее, и способом который был менее болезненным (для меня), и у меня есть больше уверенности в приложении, функционирующем как ожидалось. Еще лучше модульные тесты очень повторяемы, в этом они не зависят ни от какой модернизации UI, поэтому имеют тенденцию быть менее хрупкими как изменения в сбое дизайна в компиляции, не во времени выполнения.
Поблочное тестирование допускает более строгое тестирование производительности и делает намного легче определить, где узкие места происходят. Для крупных приложений производительность становится главной проблемой, когда 10 000 пользователей поражают метод одновременно, если тот метод берет 1/100-й из секунды для выполнения, возможно, из-за плохо записанного запроса базы данных, потому что теперь некоторые пользователи должны дождаться к 10 секундам для страницы для загрузки. Я знаю, что лично не буду ожидать, которые очень хотят, чтобы страницы загрузились и будут просто идти дальше к различному месту.
Поблочное тестирование позволяет Вам фокусироваться на логике получения данных, применения правил и проверки бизнес-процессов перед добавлением запутанности фронтэнда. К тому времени, когда модульные тесты были записаны и проведены, я знаю, что инфраструктура для приложения будет поддерживать типы данных, которые я передаю назад и вперед между процессами, что мои транзакции работают соответственно, и т.д.
, Другими словами, потенциальные точки отказа лучше изолируются к тому времени, когда Вы запускаете свои приемочные испытания, потому что Вы уже работали через потенциальные ошибки в Вашем коде с модульными тестами. С историей модульных тестов Вы будете знать, что только определенные модули бросят определенные ошибки. Это делает разыскивание кода преступника намного легче.