Лекция
Привет, Вы узнаете о том , что такое модульное тестирование, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое модульное тестирование, tdd, unit testing, блочное тестирование , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.
модульное тестирование , иногда блочное тестирование или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы, наборы из одного или более программных модулей вместе с соответствующими управляющими данными, процедурами использования и обработки.
Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.
Цель модульного тестирования — изолировать отдельные части программы и показать, что по отдельности эти части работоспособны.
Этот тип тестирования обычно выполняется программистами.
Модульное тестирование — метод повышения качества ПО при котором отдельные участки программного кода (классы, методы, функции)
тестируются на предмет адекватности поведения (отсутствие ошибок, исключения, корректные выходные параметры).
Модульное тестирование — пример автоматизированного тестирования методом белого ящика.
Модульное тестирование — пример регрессионного тестирования.
Модульное тестирование проводится разработчиками (разработка и запуск тестов).
Почему модульного тестирования важно
При этом создается код с максимально чистой функцией (методами) , для того чтобы тесты былиь изолированы от окружения (БД, сеть, файловая система, время).
разрабатывается участок программного кода (как правило новый метод или класс ).
public class Sort {
private void swap(int[] arr, int i, int j) {
int t = arr[i];
arr[i] = arr[j];
arr[j] = t;
}
public void bubblesort( int[] arr ){
for(int i = arr.length-1 ; i >= 0 ; i--){
for(int j = 0 ; j < i ; j++){
if( arr[j] > arr[j+1] )
swap(arr, j, j+1);
}
}
}
}
Размер кода должен быть сравнительно небольшой. Для таких участков легче разрабатывать модульные тесты
● Присутствие входных/выходных параметров
Для участка разрабатывается несколько модульных тестов, так чтобы были покрыты все условия и циклы,
а также комбинация различных входных выходных параметров
public class SortTestCase extends TestCase {
public void testSwap{
int[] i={1,2};
Sort sorter = new Sort();
sorter.swap(i,0,1);
AssertEquals(2, i );
AssertEquals(1, i );
}
public void testSortWithOrdinaryData(){
int[] i=new int {4,1,2};
Sort sorter = new Sort();
sorter.bubblesort(i);
AssertEquals(new int {1,2,4}, i);
}
public void testSortWithSOrtedData(){
int[] i=new int {1,2,4};
Sort sorter = new Sort();
sorter.bubblesort(i);
AssertEquals(new int {1,2,4}, i);
}
public void testSortWithEmptyData(){
int[] i=new int ;
Sort sorter = new Sort();
sorter.bubblesort(i);
AssertEquals(new int , i);
}
}
Запуск модульных тестов Через консоль
Запуск
Получение результатов
Через среду разработки (Eclipse, NetBeans,Idea PhpShtorm .
Модульное тестирование позже позволяет программистам проводить рефакторинг, будучи уверенными, что модуль по-прежнему работает корректно (регрессионное тестирование). Об этом говорит сайт https://intellect.icu . Это поощряет программистов к изменениям кода, поскольку достаточно легко проверить, что код работает и после изменений.
Модульное тестирование помогает устранить сомнения по поводу отдельных модулей и может быть использовано для подхода к тестированию «снизу вверх»: сначала тестируя отдельные части программы, а затем программу в целом.
Модульные тесты можно рассматривать как «живой документ» для тестируемого класса. Клиенты, которые не знают, как использовать данный класс, могут использовать юнит-тест в качестве примера.
Поскольку некоторые классы могут использовать другие классы, тестирование отдельного класса часто распространяется на связанные с ним. Например, класс пользуется базой данных; в ходе написания теста программист обнаруживает, что тесту приходится взаимодействовать с базой. Это ошибка, поскольку тест не должен выходить за границу класса. В результате разработчик абстрагируется от соединения с базой данных и реализует этот интерфейс, используя свой собственный mock-объект. Это приводит к менее связанному коду, минимизируя зависимости в системе.
Модульное тестирование не Грааль и не позволяет отловить 100% дефектов (out of scope: integration tests, UI tests, load and stress tests).
Тестирование программного обеспечения — комбинаторная задача. Например, каждое возможное значение булевской переменной потребует двух тестов: один на вариант TRUE, другой — на вариант FALSE. В результате на каждую строку исходного кода потребуется 3−5 строк тестового кода.
Алгоритмы вроде Marching cubes или красно-черного дерева имеют разветвленное дерево решений, и чтобы проверить все варианты, нужны огромные наборы тестов .
Как и любая технология тестирования, модульное тестирование не позволяет отловить все ошибки программы. В самом деле, это следует из практической невозможности трассировки всех возможных путей выполнения программы, за исключением простейших случаев.
Например, в математическом моделировании. Бизнес-приложения зачастую работают с конечными и счетными множествами, научные — с континуальными. Поэтому сложно подобрать тесты для каждой из ветвей программы, сложно сказать, верен ли результат, выдерживается ли точность, и т. д. А во многих случаях качество моделирования определяется «на глаз», и последний результат записывается как «опорный». Если найдено расхождение, новый результат проверяют вручную и выясняют, какой качественнее: старый или новый.
Код, взаимодействующий с портами, таймерами и прочими «нестабильными» частями системы, крайне сложно проверить в изолированном окружении.
Но это не значит, что модульное тестирование здесь полностью непригодно: оно вынуждает программиста перейти от файлов и портов, например, на абстрактные потоки. Это делает код более общим (например, без проблем можно перейти с файлов на сетевые сокеты), более тестируемым (можно даже проверить ситуацию «пропала связь»), ограничивает те части, которые не подлежат модульному тестированию.
При выполнении юнит-тестов происходит тестирование каждого из модулей по отдельности. Это означает, что ошибки интеграции, системного уровня, функций, исполняемых в нескольких модулях, не будут определены. Кроме того, данная технология бесполезна для проведения тестов на производительность. Таким образом, модульное тестирование более эффективно при использовании в сочетании с другими методиками тестирования.
Для получения выгоды от модульного тестирования требуется строго следовать технологии тестирования на всем протяжении процесса разработки программного обеспечения. Нужно хранить не только записи обо всех проведенных тестах, но и обо всех изменениях исходного кода во всех модулях. С этой целью следует использовать систему контроля версий ПО. Таким образом, если более поздняя версия ПО не проходит тест, который был успешно пройден ранее, будет несложным сверить варианты исходного кода и устранить ошибку. Также необходимо убедиться в неизменном отслеживании и анализе неудачных тестов. Игнорирование этого требования приведет к лавинообразному увеличению неудачных тестовых результатов.
За исключением простейших случаев, тестируемый объект должен взаимодействовать с другими объектами. Этих «товарищей по взаимодействию» — объекты-заглушки — делают предельно простыми: либо крайне упрощенными (память вместо базы данных), либо рассчитанными на конкретный тест и механически повторяющими сессию обмена. Проблемы могут возникать при смене протокола обмена, в таком случае объекты-заглушки должны отвечать новым требованиям протокола.
Еще о TDD
Два вида написания тестов при TDD
В самом начале тестами реализуется спецификации поведения будущего класса через входы выходы.
После успешной реализации кода, тесты корректируются и добавляются новые для поддержки всех маршрутов в коде и всех граничных входных параметров.
Особенности TDD
Использование TDD предпочтительно там, где интерфейсы классов хорошо определены.
В случае нестабильных интерфейсов, сначала необходимо довести их до «ума», после чего можно реализовывать тесты.
Advanced Unit tests
public class DataBaseReaderTestCase extends TestCase{
@Test(expected=UnauthorizedException.class) public voidtestUnauthorizedAccess(){
DatabaseReader reader = new DatabaseReaderImpl(); reader.getUsersCount();
}
}
Две точки зрения на покрытие методов класса
Для большинства популярных языков программирования высокого уровня существуют инструменты и библиотеки модульного тестирования. Некоторые из них:
Некоторые языки имеют поддержку модульного тестирования на уровне синтаксиса. Это избавляет от необходимости выбирать, к какому фреймворку привязываться, и позволяет упростить перенос кода в другие проекты.
Пример таких языков:
Пример кода на языке D
class ABC
{
this() { val = 2; }
private int val;
public func() { val *= 2; }
}
unittest
{
ABC a;
a.func();
assert( a.val > 0 && a.val < 555 ); // можно обратиться к приватной переменной внутри модуля
}
В заключение, эта статья об модульное тестирование подчеркивает важность того что вы тут, расширяете ваше сознание, знания, навыки и умения. Надеюсь, что теперь ты понял что такое модульное тестирование, tdd, unit testing, блочное тестирование и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем
Комментарии
Оставить комментарий
Разработка программного обеспечения и информационных систем
Термины: Разработка программного обеспечения и информационных систем