Объектно-ориентированное программирование разработка через тестирование



страница1/4
Дата14.06.2018
Размер0,59 Mb.
ТипУчебно-методическое пособие
  1   2   3   4
РОСЖЕЛДОР

Государственное образовательное учреждение

высшего профессионального образования

«Ростовский государственный университет путей сообщения»

(РГУПС)

А. Ломаш, Д.Е. Демидов


ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ

РАЗРАБОТКА ЧЕРЕЗ ТЕСТИРОВАНИЕ

БИБЛИОТЕКА JUNIT
Учебно-методическое пособие

Ростов-на-Дону

2009

УДК 004.45

Ломаш, Д.А.

Объектно-ориентированное программирование. Разработка через тестирование. Библиотека JUnit: учебно-методическое пособие / Д.А. Ломаш, Д.Е. Демидов; Рост. гос. ун-т путей сообщения. – Ростов н/Д, 2009. – 31 с. : ил.

Рассматриваются основные принципы разработки через тестирование при объектно-ориентированном подходе к разработке информационных систем. Основное внимание уделяется использованию библиотеки JUnit. Дается постановка задачи и приведена стратегия разработки самотестирующегося кода.

Приводятся варианты исходных заданий для самостоятельной работы и контрольные вопросы.

Рецензент д-р техн. наук, проф. М.А. Бутакова (РГУПС)

Учебное издание

Ломаш Дмитрий Алексеевич

Демидов Дмитрий Евгеньевич

ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ РАЗРАБОТКА ЧЕРЕЗ ТЕСТИРОВАНИЕ. БИБЛИОТЕКА JUNIT

Учебно-методическое пособие

Редактор А.И. Гончаров

Техническое редактирование и корректура А.И. Гончаров

Подписано в печать 15.04.2009. Формат 60x84/16.

Бумага газетная. Ризография. Усл. печ. л. 1,86.

Уч.-изд. л. 1,77. Тираж экз. Изд. № 72. Заказ № .

Ростовский государственный университет путей сообщения.

Ризография РГУПС.

Адрес университета: 344038, Ростов н/Д, пл. Ростовского Стрелкового Полка Народного Ополчения, 2.
ã Ростовский государственный университет путей сообщения, 2009

СОДЕРЖАНИЕ
Цель работы

1 Общие сведения о разработке через тестирование

2 Разработка через тестирование с использованием JUnit

3 Варианты заданий для самостоятельной работы

4 Контрольные вопросы

Библиографический список

ЦЕЛЬ РАБОТЫ
Изучить основные принципы разработки через тестирование при разработке объектно-ориентированных программ; приобрести навыки работы с библиотекой JUnit.
1 Общие сведения о разработке через тестирование
Если посмотреть, на что уходит время у большинства программистов, то окажется, что на написание кода в действительности тратится весьма небольшая его часть. Некоторое время уходит на уяснение задачи, еще какая-то его часть – на проектирование, а значительная доля поглощается отладкой.

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

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


Модульные тесты

Приемочные тесты

Определяются разработчиками

Определяются заказчиками

Тестируют небольшие модули изолированно

Тестируют приложение в целом

Низкий уровень

Высокий уровень

Выполняются достаточно быстро

Могут потребовать значительных временных затрат

Выполняются автоматически

Выполняются вручную или посредством специализированных скриптов

Пример: класс MultiCurrency выполняет сложение различных валют

Пример: годовой отчет должен содержать правильную сумму итогов по всем счетам, которые были оплачены с начала текущего года

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

Идея частого тестирования составляет важную часть экстремального тестирования (Extreme Programming – XP). Экстремальные программисты весьма привержены тестированию. Они стремятся разрабатывать программы как можно быстрее и знают, что тесты позволяют двигаться вперед с исключительной скоростью.

Итак, разработка на основе тестирования (Test Driven Development – TDD) – это набор методов, ведущих к простым программным решениям, а также тестов, подтверждающих «правильность» кода. В рамках этой методики программист выполняет следующее:



  • пишет новый код только тогда, когда автоматический тест не сработал;

  • удаляет дублирование.

Эти два довольно простых правила генерируют сложное индивидуальное и групповое поведение со множеством технических последствий:

  • проектируя код, программист постоянно запускает его и получает представление о том, как он работает, это помогает принимать правильные решения;

  • программист самостоятельно пишет собственные тесты и не ждет пока кто-то другой напишет их;

  • среда разработки должна быстро реагировать на небольшие модификации кода.

Два упомянутых правила TDD определяют порядок этапов программирования:

  • красный – напишите небольшой тест, который не работает, а возможно, даже не компилируется.

  • зеленый – заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.

  • рефакторинг – удалите из написанного вами кода любое дублирование.

Таким образом, красный – зеленый – рефакторинг – это главное правило TDD.
2 Разработка через тестирование

с использованием JUnit
JUnit является фреймворком (библиотекой) тестирования для Java. Он входит в семейство xUnit – набор утилит тестирования, охватывающий наиболее распространенные языки программирования. JUnit разрабатывался под лицензией Open Source и доступен для свободного использования по адресу http://www.junit.org.

В качестве примера разработаем фрагмент системы учета заказов, который будет включать сущности Order (Заказ), Customer (Покупатель), OrderQuery(Очередь заказов). OrderQuery должен обеспечивать возможность получения общего числа заказов в очереди, добавлять и удалять заказы, подсчитывать суммарную стоимость заказов, ожидающих обработки, а также возвращать заказ с максимальной стоимостью.



Проектная диаграмма классов разрабатываемого фрагмента представлена на рисунке 1.

Рисунок 1 – UML-диаграмма фрагмента системы учета заказов
Составим список задач, которые необходимо выполнить для того, чтобы убедиться в том, что разработанный класс работает правильно. В начале работы над задачей будем выделять ее жирным шрифтом. Закончив работу над ней, ее зачеркнем, вот так.


Получить общее количество заказов в очереди

Добавить три заказа в очередь

Получить общую стоимость заказов в очереди

Получить заказ с максимальной стоимостью

Удалить заказ с максимальной стоимостью

Для создания модульного теста следует выполнить следующие простые шаги:

1 Создать класс потомок от junit.framework.TestCase (из junit.jar).

2 Создать public-метод, возвращающий void в этом классе, который будет начинаться со слова «test». Продолжение названия метода остается на усмотрение программиста. Например, testUpdateAccount().

3 В теле метода вызвать методы тех классов, которые вы тестируете, а затем сравнить реальные возвращаемые ими значения с теми, которые вы ожидаете, с использованием assert-методов например метод assertEquals(). Варианты assert-методов приведены в таблице 2.
Таблица 2 – Различные assert-методы фреймворка Junit


Метод

Описание

assertEquals(Object expected, Object actual);

assertEquals(String message, Object expected,

Object actual);


Проверяет два объекта на равенство, используя стандартный метод Object.equals(). Также существуют перегруженные версии этого метода для всех примитивных типов

assertTrue(boolean condition);

assertTrue(String message, Boolean condition);

Проверяет, что значение является истинным

assertFalse(boolean condition);

assertFalse(String message, boolean condition);

Проверяет, что значение является ложным

assertNull(Object value);

assertNull(String message,Object value);

Проверяет объектную ссылку на null

assertNotNull(Object value);

assertNotNull(String message, Object value);

Проверяет, что объектная ссылка не null

assertSame(Object expected, Object actual);

assertSame(String message, Object expected,

Object actual);

Проверяет, что объекты являются одними и теми же, – то, что они ссылаются на один объект

assertNotSame(Object expected, Object actual);

assertNotSame(String message, Object expected,

Object actual);

Проверяет, что оба значения не являются одинаковыми ссылками


Каталог: site -> assets -> files
files -> Основная образовательная программа высшего образования
files -> Зарубежный опыт нравственного воспитания молодёжи посредством культурного и природного наследия: теоретические походы
files -> Статья Основные принципы законодательства о градостроительной деятельности Статья Законодательство о градостроительной деятельности
files -> Маршруты культурного наследия Совета Европы как общеевропейская модель нравственного воспитания молодёжи
files -> Программа-минимум кандидатского экзамена по специальности 08. 00. 14 «Мировая экономика» по экономическим наукам
files -> Программа-минимум кандидатского экзамена по специальности
files -> Маркетинговые исследования рынка
files -> Программа минимум кандидатского экзамена по курсу «История и философия науки» «История педагогики»
files -> Рассказанная мовсесом хоренаци по просьбе сахака багратуни մՈՎՍԷՍ ԽՈՐԵՆԱՑԻ ՀԱՅՈՑ ՊԱՏՄՈՒԹԻՒՆ
files -> Проектирование участка новой железной дороги


Поделитесь с Вашими друзьями:
  1   2   3   4


База данных защищена авторским правом ©grazit.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал