Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Старое ПППП / Лабораторная работа №5 / Лабораторная работа №5

.pdf
Скачиваний:
109
Добавлен:
17.04.2018
Размер:
523.06 Кб
Скачать

Практикум по промышленному программированию ­ 2015. Лабораторная работа №5

Лабораторная работа №5 Автоматизация сборки с помощью Gradle. Тестирование с помощью JUnit

Цель работы: ознакомиться с автоматизированной сборкой приложений, научиться использовать инструмент Gradle для сборки, запуска тестов и генерации документации, закрепить навыки написания модульных тестов для программ, освоить навыки написания интеграционных тестов.

Необходимое ПО для практической части: JDK 8; IntelliJ IDEA 14 Community Edition; Gradle.

Теоретические сведения

Автоматизация сборки — этап написания скриптов или автоматизация широкого спектра задач, применяемого разработчиками в их повседневной деятельности. Включает в себя такие действия, как:

компиляция исходного кода в бинарный код;

сборка бинарного кода;

выполнение тестов;

разворачивание программы на производственной платформе;

написание сопроводительной документации или описание изменений новой версии.

Преимущества

Улучшение качества продукта;

Ускорение процесса компиляции и линковки;

Избавление от излишних действий;

Минимизация «плохих (некорректных) сборок»;

Избавление от привязки к конкретному человеку;

Ведение истории сборок и релизов для разбора выпусков;

Экономия времени и денег благодаря причинам, указанным выше.

Типы автоматизации сборки

Автоматизация по запросу (On­Demand automation): запуск пользователем скрипта в командной строке.

Запланированная автоматизация (Scheduled automation): непрерывная интеграция,

происходящая в виде ночных сборок.

Условная автоматизация (Triggered automation): непрерывная интеграция, выполняющая сборку при каждом подтверждении изменения кода (commit) в системе управления версиями.

Система сборки Gradle

Gradle — система автоматической сборки, предоставляющая предметно­ориентированный язык (DSL) на языке Groovy вместо традиционной XML­образной формы представления конфигурации проекта. Она также предоставляет возможности управления зависимостями.

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

Система сборки помогает со сборкой и упаковкой приложения без привязки к определенной среде разработки. Это особенно полезно, если вы используете сервер для сборки или непрерывной интеграции(CI), где среды разработки не всегда доступны. Вместо этого сервер сборки может вызвать систему сборки, предоставляя конфигурации для сборки, так что система знает, как собрать приложение для различных платформ.

­1­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №5

В случае с Gradle, управление зависимостями и система сборки идут рука об руку. Они настроены таким же набором файлов.

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

Основные плагины предназначены для разработки и развертывания Java, Groovy и Scala приложений, но готовятся плагины и для других языков программирования.

Модульное (юнит) тестирование

Необходимые теоретические сведения по модульному тестированию приведены в приложенном файле лабораторной работы из курса “Тестирование ПО”.

Интеграционное тестирование

Интеграционное тестирование ­ это тестирование части системы, состоящей из двух и более модулей. Основная задача интеграционного тестирования ­ поиск дефектов, связанных с ошибками в реализации и интерпретации интерфейсного взаимодействия между модулями. Иначе говоря, оно предназначено для проверки связи между компонентами, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами).

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

На рисунке приведена структура комплекса программ K, состоящего из оттестированных на этапе модульного тестирования модулей M1, M2, M11, M12, M21, M22. Задача, решаемая методом интеграционного тестирования, ­ тестирование межмодульных связей, реализующихся при исполнении программного обеспечения комплекса K. Интеграционное тестирование использует модель "белого ящика" на модульном уровне. Поскольку тестировщику текст программы известен с детальностью до вызова всех модулей, входящих в тестируемый комплекс, применение структурных критериев на данном этапе возможно и оправдано.

Практическая часть

Обратите внимание, что в нижеприведенных инструкциях используется версия IntelliJ IDEA 14.1. Это важно, так как в версии 14.1 немного переработан интерфейс работы с системой сборки Gradle.

­2­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №5

Создание Gradle-проекта

Создадим проект, использующий в качестве системы сборки Gradle.

­3­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №5

Если вы выберете “Use default gradle wrapper”, то среда скачает Gradle за вас сама. Если вы хотите использовать свою ранее установленную систему Gradle, то выберите “Use local gradle distribution” и укажите папку с установленной системой Gradle. В приведенном объяснении используется первый вариант.

Далее вводите имя проекта и заканчиваете первоначальную настройку.

Файл build.gradle

В файле build.gradle (в корне созданного проекта) находится скрипт, который и отвечает за все необходимые действия сборки в Gradle. Разберем его.

Строка

apply plugin: 'java'

позволяет выполнять необходимые действия для java­проектов, такие, как запуск программы, сборка, запуск тестов, генерация документации.

Строка sourceCompatibility = 1.5

означает, что при сборке Java­проекта код будет проверяться на совестимость с версией Java 5 (то есть будут недоступны, к примеру, try­with­resourses). Для совместимости с последней версией Java 8 необходимо изменить значение на “1.8”.

Строка

version = '1.0'

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

Строки repositories {

mavenCentral()

}

dependencies {

testCompile group: 'junit', name: 'junit', version: '4.11'

}

определяют, где искать библиотеки для подключения. В них указано, что нужно искать библиотеки в репозитории Maven Central, где хранятся многие из необходимых библиотек, в том числе и JUnit. При первой сборе Gradle самостоятельно скачает библиотеку нужной версии.

В IntelliJ IDEA 14.1 доступен специальный “вид” с задачами (справа), которые может выполнять Gradle с конфигурацией, заданной в build.gradle.

­4­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №5

Эти задания (task) можно выполнить двойным нажатием. Необходимые команды:

build ­ сборка проекта;

clean ­ очистка проекта (очищаются все временные файлы, при следующей сборке все сгенерированные файлы создаются заново);

javadoc ­ генерация документации javadoc (подробнее об этом ниже); test ­ запуск (прогон) всех тестов.

Подробнее о плагине java ­ по этой ссылке http://gradle.org/docs/current/userguide/java_plugin.html.

Также полезно подключить плагин “application” для добавления дополнительных возможностей, в частности, запуска приложения.

В файл build.gradle:

apply plugin: 'application'

Подробнее о плагине application: http://gradle.org/docs/current/userguide/application_plugin.html.

Затем нужно попросить обновить Gradle­проект для того, чтобы можно было выполнить новые команды.

run ­ запуск приложения.

­5­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №5

Создание приложения, собираемого Gradle

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

Директория

Содержимое директории

 

 

src/main/java

Исходный Java­код

 

 

src/test/java

Исходный код тестов

 

 

После создания этих директорий должно получиться примерно следующее.

Папка java в main помечена синим цветом, а в test ­ зеленым, это значит ­ папка исходных кодов и папка исходных кодов для тестов соответственно.

Добавим исходный код для небольшой программы. package com.example.circle;

public class Circle {private double radius;

public Circle(double radius) {

this.radius = radius;

}

public double getArea() {

return Math.PI * radius * radius;

}

public static void main(String[] args) { Circle circle = new Circle(11.7); System.out.println(circle.getArea());

}

}

Однако для того, чтобы команда run заработала, необходимо явно указать класс, который является запускаемым (тот, в котором находится метод public static void main) включением в build.gradle строчки:

mainClassName = "com.example.circle.Circle"

­6­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №5

Создание тестов

Напишем модульный тест для примера. В примере не указан интеграционный тест, т.к здесь нет материала для интеграционного теста, однако в своем варианте самостоятельного варианта необходимо будет его сделать.

В папке для тестов создадим тест для класса Circle. import com.example.circle.Circle; import org.junit.Assert;

import org.junit.Test;

public class CircleTest {

@Test

public void testArea(){

Circle circle = new Circle(1.0); Assert.assertEquals(3.1415, circle.getArea(), 0.0001

}

}

Теперь команда test в Gradle будет запускать этот тест, и выдавать результат. А также генерировать отчет о тестировании в формате HTML, который может быть найден в каталоге

\build\reports\tests.

­7­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №5

Генерация документации

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

Во­вторых, в настройках проекта (File­>Settings) необходимо указать кодировку проекта UTF­8.

Для генерации документации Gradle вызывает специальную утилиту, называемую javadoc. Чтобы сгенерировать документацию, этой утилите необходимо особым образом комментировать исходный код. Именно из таких комментариев и будет генерироваться документация.

­8­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №5

Подробнее о том, как записывать javadoc­комментарии: https://ru.wikipedia.org/wiki/Javadoc http://www.ibm.com/developerworks/ru/library/j­jtp0821/index.html

После добавления комментариев в исходный код можно сгенерировать документацию Gradle командой javadoc. Она будет сохранена в \build\docs\javadoc. В Firefox кодировка файла самостоятельно не распознается, так что при просмотре javadoc­документации, надо самостоятельно выбрать кодировку

“Unicode”.

Git

Если возникнет необходимость использования СКВ, то последовательность действий следующая. Создание проекта ­ как описано выше. Далее: VCS ­> Enable Version Control Integration, в диалоговом окне выбрать Git. Далее: VCS ­ > Import into Version Control ­> Share Project on GitHub.

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

Задание выполняется индивидуально. Необходимо создать Gradle­проект согласно варианту, в котором необходимо обеспечить:

1.программную реализацию с GUI

2.модульное и интеграционное тестирование (JUnit тесты)

3.документацию (javadoc)

Рекомендуется использовать Java Time API, введенный в Java 8. http://www.oracle.com/technetwork/articles/java/jf14­date­time­2125367.html http://www.mscharhag.com/2014/02/java­8­datetime­api.html

Вариант 1, 7, 13, 19, 25

Цифровые часы для нескольких часовых поясов

Вариант 2, 8, 14, 20, 26

Часы со стрелками

Вариант 3, 9, 15, 21, 27

Секундомер

Вариант 4, 10, 16, 22, 28

Таймер

Вариант 5, 11, 17, 23, 29

Календарь

Вариант 6, 12, 18, 24, 30

Расчет времени между двумя событиями

Литература, ссылки

1.http://gradle.org/docs/current/userguide/userguide

2.https://www.jetbrains.com/idea/help/gradle­2.html

3.https://ru.wikipedia.org/wiki/%C0%E2%F2%EE%EC%E0%F2%E8%E7%E0%F6%E8%FF_%F1% E1%EE%F0%EA%E8

4.https://ru.wikipedia.org/wiki/%C8%ED%F2%E5%E3%F0%E0%F6%E8%EE%ED%ED%EE%E5_% F2%E5%F1%F2%E8%F0%EE%E2%E0%ED%E8%E5

­9­