Главная страница
Навигация по странице:

  • Лабораторная работа № 9. Модульное тестирование приложения

  • 9.1. Система модульного тестирования JUnit

  • 9.2. Разработка JUnit-теста

  • 9.3. Запуск JUnit-тестов в среде Eclipse

  • 9.4. Порядок выполнения лабораторной работы

  • Лабораторная работа № 10. Протоколирование работы приложения

  • 10.1. Понятие протоколирования работы приложения

  • 10.2. Библиотека ведения протоколов Log4j

  • БЖД методичка. Метод указания лаб - последняя редакция (1). Методические указания к лабораторным работам СанктПетербург Издательство спбгэту лэти 2013


    Скачать 1.15 Mb.
    НазваниеМетодические указания к лабораторным работам СанктПетербург Издательство спбгэту лэти 2013
    АнкорБЖД методичка
    Дата06.09.2021
    Размер1.15 Mb.
    Формат файлаpdf
    Имя файлаМетод указания лаб - последняя редакция (1).pdf
    ТипМетодические указания
    #229976
    страница5 из 6
    1   2   3   4   5   6
    8.5. Порядок выполнения лабораторной работы
    1. Создайте новый проект, который будет дублировать проект лабораторной работы № 7.
    2. В новом проекте опишите 3 параллельных потока, один из которых будет загружать данные из XML-файла, второй

    редактировать данные и формировать XML-файл для отчета, а третий

    строить отчет в HTML- формате. Второй поток не должен формировать XML-файл для отчета, пока первый не загрузит данные в экранную форму, а третий поток не должен формировать отчет, пока второй поток редактирует данные и записывает их в
    XML-файл.
    3. С помощью конструктора подготовьте шаблон для отчета.
    4. Запустите приложение и убедитесь, что сформирован HTML-файл.
    Просмотрите его в браузере и проверьте правильность данных и формы.
    5. Сгенерируйте документацию с помощью Javadoc и просмотрите ее в браузере.
    8.6. Содержание отчета
    Отчет по лабораторной работе должен содержать:
    1. Исходный и отредактированный XML-файлы.
    2. Скриншот построенного отчета.
    3. Текст документации, сгенерированный Javadoc.
    4. Фрагменты кода, отвечающие за организацию параллельной работы трех потоков.
    Лабораторная работа № 9. Модульное тестирование приложения
    Цель работы: знакомство с технологией модульного тестирования Java- приложений с использованием системы JUnit.
    9.1. Система модульного тестирования JUnit
    Тестирование приложения является неотъемлемой частью цикла разра- ботки, а написание и поддержка модульных тестов могут гарантировать кор- ректную работу отдельных компонентов исходного кода (класса, метода).
    Модульное тестирование заключается в проверке того, как тот или иной компонент поведет себя в различных ситуациях. Например, как метод объек- та ведет себя при различных входных данных. Модульные тесты обычно пи- шутся программистами и служат для первичной проверки того, что внесен- ные изменения не изменили поведение отдельных компонентов системы.

    50
    В языке Java для создания и запуска модульных тестов используется библио- тека
    JUnit, которую можно загрузить с адреса https://github.com/KentBeck/junit/downloads
    . После распаковки архива биб- лиотеки ее надо подключить к проекту, используя пункт меню Build Path →
    Configure Build Path. В открывшемся окне выбрать вкладку Libraries и нажать кнопку Add External JARs, после чего в диалоговом окне указать, в каком ка- талоге находится файл junit-4.11.jar.
    9.2. Разработка JUnit-теста
    JUnit-тест – это класс, проверяющий работоспособность методов дру- гого класса. Для установки соответствия между этими двумя классами JUnit- тест именуют так же, как тестируемый класс, с добавлением к нему суффикса
    Test, например Lab9Test. Методы внутри JUnit-теста должны быть объявле- ны как public void без формальных параметров, а их имена должны совпа- дать с именами тестируемых методов, предваряя их префиксом test, напри- мер public void testShow(). В JUnit-тесте перед описанием каждого тести- рующего метода необходимо указать аннотацию @Test. Если JUnit-метод проверяет, как тестируемый метод реагирует на исключение, то в аннотацию
    JUnit-метода надо включить имя класса исключительной ситуации:
    @Test(expected=Имя.class). В этом случае при возникновении исключитель- ной ситуации в проверяемом методе JUnit-метод не завершится ошибкой.
    Сами тесты состоят из выполнения некоторого кода и проверок. Про- верки чаще всего выполняются с помощью класса Assert. Методы класса
    Assert сравнивают фактическое значение, возвращаемое тестом, с ожидае- мым значением и вызывают AssertionException, если тест на сравнение не пройден. Основные методы класса Assert приведены в таблице.
    Методы класса Assert
    Описание методов static void assertTrue (boolean condition)
    Утверждает, что условие истинно static void assertFalse (boolean condition)
    Утверждает, что условие ложно static void assertEquals (java.lang.Object ex- pected, java.lang.Object actual)
    Утверждает, что 2 значения равны static void assertNotEquals (java.lang.Object ex- pected, java.lang.Object actual)
    Утверждает, что 2 значения не равны static void assertNull (java.lang.Object object)
    Утверждает, что объект равен null static void assertNotNull (java.lang.Object object) Утверждает, что объект не равен null

    51
    Окончание таблицы
    Методы класса Assert
    Описание методов static void assertSame (java.lang.Object expected, java.lang.Object actual)
    Утверждает, что 2 объекта ссылаются на один и тот же объект static void assertNotSame (java.lang.Object expected, java.lang.Object actual)
    Утверждает, что 2 объекта ссылаются не на один и тот же объект
    В тестируемом классе для тестовых методов можно использовать также аннотации @Before, @After, @BeforeClass, @AfterClass. Методы, которые снабжены такой аннотацией, будут вызываться соответственно: в начале каждого метода, в конце каждого метода, в начале тестирования, в конце тес- тирования. Необходимо обратить внимание, что методы с аннотациями
    @Before и @After не должны быть static, а методы с аннотациями
    @BeforeClass и @AfterClass должны быть static.
    Для тестирования корректности работы кода при возникновении ис- ключительных ситуаций, нужно в аннотации @Test метода, генерирующего исключительную ситуацию, указать имя класса ожидаемого исключения:
    @Test(expected=Имя.class).
    При составлении JUnit-теста целесообразно учесть следующие реко- мендации:

    тестовый метод должен быть коротким;

    количество проверок (assert) должно быть минимальным;

    каждый тест должен покрывать одну логическую единицу (метод, одну ветвь конструкции if..else, один из случаев (case) блока switch, исклю- чение и т. д.).
    Для примера рассмотрим составление JUnit-теста для класса, в котором первый метод возвращает истину, если значение строки null или пусто, вто- рой

    реализует операцию сложения: public class Util { public static boolean isEmpty(String value) { return value == null || "".equals(value);
    } public static int sum(int x, int y) { return x + y;
    }}
    JUnit-тесты для проверки методов этого класса будут такими:

    52 package edu.leti.book.test; // Отдельный пакет для тестов import org.junit.Test; // Подключаем классы JUnit import org.junit.Assert; // Подключаем методы Assert public class UtilTest {
    @Test public void testisEmpty() {
    Assert.assertTrue(Util.isEmpty(null)); // Проверяем на null
    Assert.assertTrue(Util.isEmpty("")); // Проверяем на пусто
    }
    /** Данный тест проверяет метод isEmpty на корректную обработку непустых зна- чений ( возвращает «ложь» при получении строки, содержащей хотя бы один символ.*/
    @Test public void testNonisEmpty() {
    Assert.assertFalse(Util.isEmpty(" ")); // Проверяем на пробел
    Assert.assertFalse(Util.isEmpty("some string")); // Проверяем на непустую строку
    }
    @Test public void testSum() {
    Assert.assertEquals(4, Util.sum(2, 2)); // Проверяем на 2 + 2 = 4
    Assert.assertNotEquals(5, Util.sum(2, 2)); // Проверяем 2 + 2 ≠ 5
    }
    @Test(expected = RuntimeException.class) // Проверяем на появление исключения public void testException() { throw new RuntimeException("Ошибка");
    }
    @BeforeClass // Фиксируем начало тестирования public static void allTestsStarted() {
    System.out.println("Начало тестирования");
    }
    @AfterClass // Фиксируем конец тестирования public static void allTestsFinished() {
    System.out.println("Конец тестирования");
    }
    @Before // Фиксируем запуск теста public void testStarted() {
    System.out.println("Запуск теста");
    }
    @After // Фиксируем завершение теста public void testFinished() {
    System.out.println("Завершение теста");
    }
    }

    53
    9.3. Запуск JUnit-тестов в среде Eclipse
    Тестовые классы JUnit можно исполнять как с помощью интегрированной среды разработки Eclipse (рисунок), так и с помощью интерфейса командной строки.
    Запуск JUnit-тестов в среде Eclipse
    При запуске тестов JUnit в среде Eclipse необходимо в дереве Package
    Explorer выделить класс, содержащий JUnit-тесты, нажать правую клавишу мыши и в выпадающем меню выбрать «Run As... → JUnit Test». Откроется область JUnit, и в случае успешного выполнения всех тестов значение неудач (Failures) будет равно нулю, в противном случае это значение будет показывать число невыполненных тестов.

    54
    9.4. Порядок выполнения лабораторной работы
    1. Создайте новый проект, который будет дублировать проект лабораторной работы № 3.
    2. Проанализируйте классы приложения и определите, какие методы необходимо протестировать.
    3. Напишите JUnit-тесты для выбранных методов.
    4. Запустите тесты и снимите с экрана скриншоты, иллюстрирующие выполнение тестов.
    5. Сгенерируйте документацию с помощью Javadoc и просмотрите ее в браузере.
    9.5. Содержание отчета
    Отчет по лабораторной работе должен содержать:
    1. Перечень методов, которые тестируются в приложении.
    2. Исходные тексты классов тестов.
    3. Скриншоты, иллюстрирующие выполнение тестов.
    4. Текст документации, сгенерированный Javadoc.
    Лабораторная работа № 10. Протоколирование работы приложения
    Цель работы: знакомство с методами протоколирования работы при- ложения с использованием библиотеки Log4j.
    10.1. Понятие протоколирования работы приложения
    На этапе разработки приложения программист обычно пользуется по- шаговыми средствами отладки, встроенными в инструментальную среду
    Eclipse (см. лабораторную работу № 1), и Unit-тестированием (см. лабора- торную работу № 9). В ряде случаев бывает неудобно или невозможно поль- зоваться такими средствами. Например, при работе с отладчиком виден лишь небольшой фрагмент программы, что не всегда дает возможность по- нять причины возникновения ошибок; кроме того, приложение может быть установлено в рабочую среду, где нет инструментов разработки и отладки программы. В этом случае для контроля и анализа работы приложения используют методы протоколирования. Этот способ является одним из ос- новных для выявления ошибок в том случае, если приложение запускается на удаленном компьютере. Задача протоколирования – проанализировать рабо- ту приложения и быстро найти дефект в его работе. Протоколирование за- ключается в формировании и выводе списка событий, происходящих в про-

    55 грамме во время ее выполнения. В протокол полезно записывать следующую информацию о событии:

    дата/время события;

    название события;

    имя выполняемого модуля и метода;

    значения параметров, описания исключений;

    идентификатор пользователя;

    стек вызовов.
    Выбор и реализация методов протоколирования – очень важная задача, от реализации которой зависит скорость и качество обнаружения и исправле- ния дефектов и качество сопровождения программы.
    10.2. Библиотека ведения протоколов Log4j
    В Java для протоколирования работы приложений используются раз- личные библиотеки: JDK logging utils, log4j, Logback, x4juli, Simple Log. Наи- более популярным инструментом для этих целей является библиотека Log4j, которая разработана Apache Software Foundation и текущую версию которой можно загрузить с http://logging.apache.org/log4j/1.2/download.html
    . Из загру- женного архива надо извлечь библиотеку log4j-1.2.17.jar и подключить ее к своему проекту, используя пункт меню Build Path → Configure Build Path.
    В открывшемся окне необходимо выбрать вкладку Libraries и нажать кнопку
    Add External JARs, после чего в диалоговом окне указать, в каком каталоге находится файл log4j-1.2.17.jar.
    Для использования библиотеки необходимо в каталоге рабочей области проекта src\java создать конфигурационный файл, который описывает, что, куда и как нужно протоколировать. Управление протоколированием выпол- няется посредством редактирования конфигурационного файла, без измене- ния исходного кода программы.
    Конфигурирование в Log4J может осуществляться двумя способами – через файл свойств и через xml-файл. Соответственно они называются log4j.properties и log4j.xml. В лабораторной работе для описания конфигура- ции протоколирования будем использовать файл свойств. Для построения конфигурационного файла необходимо определить 3 составляющие:
    1) какая информация должна отображаться в протоколе;
    2) в каком формате ее представлять, как ее группировать или разде- лять;

    56 3) куда выводить информацию, какой максимальный объем требу- ется хранить единовременно.
    Для описания этих составляющих в Log4J используются следующие объекты: logger, layout и appender.
    Logger представляет собой объект класса org.apache.log4j.Logger, кото- рый используется для вывода сообщений и управления уровнем (детализаци- ей) вывода. Он поддерживает следующие уровни вывода, в порядке возрас- тания: TRACE (очень подробная отладочная информация), DEBUG (менее подробная отладочная информация), INFO (вывод сообщений), WARN (пре- дупреждения), ERROR (ошибки), FATAL (фатальные ошибки), OFF (запрет вывода). Установка определенного уровня означает следующее – сообщения, выводимые с этим или более высоким уровнем, будут перехватываться. Со- общения, выводимые с уровнем ниже установленного, перехватываться не будут.
    Layout задает формат (компоновку) вывода сообщений и использует базовый класс org.apache.log4j.Layout. Он имеет несколько наследников, и у каждого из них свое предназначение и свои возможности. Наиболее простой вариант компоновщика org.apache.log4j.SimpleLayout, который позволяет пе- редавать на выход неформатированный текст сообщения. Но в таком тексте разбираться очень трудно.
    Хорошо читаемый текст можно получить, используя компоновщик org.apache.log4j.PatternLayout. Он позволяет задать шаблонную строку для форматирования выводимого сообщения, похожую на ту, которая использу- ется в операторе printf языка Си. Описание формата начинается со знака '%', после которого (возможно) идет модификатор формата и дальше символ, обозначающий тип выводимых данных. В таблице приведен перечень ос- новных символов, используемых для обозначения типов выводимых данных.
    Символ
    Тип данных
    Примечание с
    (прописной)
    Составное имя источника сообщения, разделенное символом точка
    После символа «c» в фигурных скобках мо- жет следовать число – сколько частей с конца составного имени источника выводить d
    Дата и/или время
    В фигурных скобках после символа «d» ука- зывается формат вывода даты и/или времени
    – DATE (дата и время) , ABSOLUTE (время) или ISO8601 (время и дата)

    57
    Окончание таблицы
    Символ
    Тип данных
    Примечание l
    Полная информация о точ- ке генерации сообщения.
    Содержит имена класса, метода, файла и строку, в которой было сгенерировано сооб- щение
    L
    Номер строки, в которой произошел вызов записи сообщения

    m
    Сообщение, которое про- токолируется

    M
    Имя метода, в котором бы- ло сгенерировано сообще- ние

    n
    Перевод строки

    p
    Приоритет сообщения
    Выводит название уровня сообщения t
    Имя потока
    Выводит имя потока, в котором сгенерирова- но сообщение
    Компоновщик PatternLayout поддерживает также позиционное форма- тирование. Оно означает, что для каждого выводимого типа данных можно задать минимальный и максимальный размеры значения, а также выравнива- ние, если значение меньше минимальной выделенной области. Модификато- ры форматирования задаются между символом '%' и типом выводимых дан- ных. Например, формат вывода «%-15.25c» означает, что отводится минимум
    15 и максимум 25 символов под имя категории, если длина значения меньше
    – выравнивает его по левому краю поля, если больше – обрезает с начала, ос- тавляя 25 символов. Для повышения читабельности сообщений в шаблон можно включать любые символы помимо тех, которые задают формат выво- димых типов данных.
    Appender

    это объект, определяющий, куда будут выводиться сообще- ния. Чаще всего это консоль (ConsoleAppender) и файлы с различными спо- собами формирования
    (FileAppender,
    RollingFileAppender,
    DailyRollingFileAppender). При способе формирования FileAppender со- общения добавляются в файл, пока не переполнится диск. Такой способ можно использовать, когда выводится небольшое число сообщений. Способ
    RollingFileAppender позволяет ротировать лог-файл по достижении опреде- ленного размера, т. е. каждый раз будет открываться новый файл при дости-

    58 жении текущим файлом максимального размера.
    Способ
    DailyRollingFileAppender позволяет не только ротировать файл, но и задавать частоту ротации (раз в день, в месяц, в час и т. д.). Свойства объекта appender описываются следующей строкой: log4j.appender.<ИМЯ_ Appender >.<СВОЙСТВО>=<ЗНАЧЕНИЕ>
    Порядок описания свойств не важен, а их перечень можно узнать в до- кументации JavaDoc.
    Ниже представлен пример записей для конфигурационного файла свойств: log4j.rootLogger=INFO, test log4j.appender.test=org.apache.log4j.FileAppender log4j.appender.test.file=myproject.log log4j.appender.test.Encoding=Cp1251 log4j.appender.test.layout=org.apache.log4j.PatternLayout log4j.appender.test.layout.conversionPattern=%d{ABSOLUTE} %5p %t
    %c{1}:%M:%L - %m%n
    Первая строка описывает уровень cообщений (INFO и все выше него), которые нужно перехватывать, и символическое название устройства (test), на которое будут выводиться сообщения; вторая строка указывает, что со- общения будут записываться в файл; третья строка задает имя этого файла
    (myproject.log); четвертая строка определяет кодировку символов сообщений; пятая строка указывает, что для вывода сообщений будет использоваться шаблон PatternLayout, а в шестой описывается формат вывода сообщения.
    Формат вывода сообщений задается через свойство conversionPattern, в кото- ром определен следующий порядок вывода данных в сообщении:

    время в формате ч: мин: с, мс (параметр %d{ABSOLUTE});

    уровень вывода сообщения длиной 5 символов (параметр %5p);

    имя потока, который вывел сообщение (параметр %t);

    имя класса (последняя часть составного имени источника сообщений
    (параметр %c{1}));

    имя метода, который вызвал запись сообщения (параметр %M);

    номер строки, в которой произошел вызов записи сообщения (пара- метр %L);

    сообщение, которое протоколируется (параметр %m);

    перевод строки (параметр %n).

    59
    Для повышения читаемости сообщений в формат вывода между име- нем класса, именем метода и номером строки включены разделители «:» , а между номером строки и текстом сообщения разделитель «-».
    1   2   3   4   5   6


    написать администратору сайта