Тестирование. Пакет JUnitСегодня большую популярность приобретает test-driven development(TDD), техника разработки ПО, при которой сначала пишется тест на определенный функционал, а затем пишется реализация этого функционала. В результате код не только написан и протестирован, но тесты как
Слайд 2
Тестирование. Пакет JUnit Сегодня большую популярность приобретает test-driven development(TDD),
техника разработки ПО, при которой сначала пишется тест на
определенный функционал, а затем пишется реализация этого функционала. В результате код не только написан и протестирован, но тесты как бы неявно задают требования к функционалу, а также показывают пример использования этого функционала.
Слайд 3
Самым известным фреймворком является JUnit. Используется он в
двух вариантах JUnit 3 и JUnit 4 JUnit 3 Для
создания теста нужно унаследовать тест-класс от TestCase, переопределить методы setUp и tearDown если надо, а также создать тестовые методы(должны начинаться с test).
При запуске теста сначала создается экземпляр тест-класса(для каждого теста в классе отдельный экземпляр класса), затем выполняется метод setUp, запускается сам тест, ну и в завершение выполняется метод tearDown. Если какой-либо из методов выбрасывает исключение, тест считается провалившимся.
Тестовые методы должны быть public void, могут быть static.
Слайд 4
Сами тесты состоят из выполнения некоторого кода и
проверок. Проверки чаще всего выполняются с помощью класса Assert
хотя иногда используют ключевое слово assert. Рассмотрим пример. Пусть имеется класс, который имеет два метода - нахождение факториала и суммы двух чисел: public class MathFunc { private int variable; public MathFunc() { variable = 0; } public MathFunc(int var) { variable = var; }
Слайд 5
public int getVariable() { return variable; }
public long factorial() { long result = 1; if (variable > 1) { for (int i=1; i<=variable; i++) result = result*i; } return result; }
public long plus(int var) { long result = variable + var; return result; } }
Слайд 6
Напишем для этого класса тесты, используя JUnit 3. Удобнее
всего, писать тесты, рассматривая некий класс как черный ящик,
писать отдельный тест на каждый значимый метод в этом классе, для каждого набора входных параметров какой-то ожидаемый результат. Для написания тестового класса нужно создать наследника junit.framework.TestCase. Затем необходимо определить конструктор, принимающий в качестве параметра строку (String) и передающую ее родительскому классу.
Слайд 7
import junit.framework.*; public class TestClass extends TestCase {
public TestClass(String testName) { super(testName); } public
void testFactorialNull() { MathFunc math = new MathFunc(); assertTrue(math.factorial() == 1); }
public void testFactorialPositive() { MathFunc math = new MathFunc(5); assertTrue(math.factorial() == 120); }
public void testPlus() { MathFunc math = new MathFunc(45); assertTrue(math.plus(123) == 168); } }
Слайд 8
Метод assertTrue проверяет, является ли результат выражения верным.
Некоторые другие методы, которые могут пригодиться - assertEquals, assertFalse,
assertNull, assertNotNull, assertSame. Стоит заметить, что assertEquals и assertSame отличаются: assertSame(Object expect, Object actual) Эквивалентно expect == actual assertEquals(Object expect, Object actual) Эквивалентно expect.equals(actual). Для того, чтобы объединить тесты, можно воспользоваться классом TestSuite с его методом addTest. Наконец, для запуска всех тестов нужно воспользоваться TestRunner. Можно использовать текстовый junit.textui.TestRunner (есть также графические версии - junit.swingui.TestRunner, junit.awtui.TestRunner). В итоге метод main имеет вид:
new TestRunner(); TestSuite suite = new TestSuite(); suite.addTest(new TestClass(“testFactorialNull”)); suite.addTest( new TestClass(“testFactorialPositive”)); suite.addTest(new TestClass(“testPlus”)); runner.doRun(suite); } }
классов, могут пригодится методы setUp и tearDown. Первый метод
может проинициализировать один или несколько экземпляров тестируемого класса для использования в нескольких TestCases, второй метод отпускает захваченные при инициализации ресурсы.
Слайд 11
Наследуя тест-класс от ExceptionTestCase, можно проверить что-либо на
выброс исключения.
JUnit 4 Здесь была добавлена поддержка новых возможностей из
Java 5, тесты теперь могут быть объявлены с помощью аннотаций. При этом существует обратная совместимость с предыдущей версией фреймворка.
Слайд 12
Основные аннотации Аннотация @Before обозначает методы, которые будут вызваны
до исполнения теста, методы должны быть public void.
Здесь обычно размещаются предустановки для теста. Аннотация @BeforeClass обозначает методы, которые будут вызваны до создания экземпляра тест-класса, методы должны быть public static void. Имеет смысл размещать предустановки для теста в случае, когда класс содержит несколько тестов использующих различные предустановки, либо когда несколько тестов используют одни и те же данные.
Слайд 13
Аннотация @After обозначает методы, которые будут вызваны после
выполнения теста, методы должны быть public void. Здесь размещаются
операции освобождения ресурсов после теста.
Аннотация @AfterClass связана по смыслу с @BeforeClass, но выполняет методы после теста, как и в случае с @BeforeClass, методы должны быть public static void.
Слайд 14
Аннотация @Test обозначает тестовые методы. Как
и ранее, эти методы должны быть public void.
Здесь размещаются сами проверки. Кроме того, у данной аннотации есть два параметра, expected — задает ожидаемое исключение и timeout — задает время, по истечению которого тест считается провалившимся. Пример: @Test(expected = NullPointerException.class) public void testToHexStringWrong() { StringUtils.toHexString(null); }
@Test(timeout = 1000) public void infinity() { while (true); }
Слайд 15
Если какой-либо тест по какой-либо серьезной причине нужно
отключить(например, этот тест постоянно валится, но его исправление отложено)
его можно зааннотировать @Ignore. Пример: @Ignore @Test(timeout = 1000) public void infinity() { while (true); }
Слайд 16
Рассмотрим пример: @RunWith(JUnit4.class) public class JUnit4Test extends Assert { private
final Map toHexStringData
= new HashMap() @Before public void setUpToHexStringData() { toHexStringData.put("", new byte[0]); toHexStringData.put("01020d112d7f", new byte[] { 1, 2, 13, 17, 45, 127 }); toHexStringData.put("00fff21180", new byte[] { 0, -1, -14, 17, -128 });
//... }
Слайд 17
@After public void tearDownToHexStringData() {
toHexStringData.clear(); } @Test public void testToHexString() {
for (Map.Entry entry : toHexStringData.entrySet()){ final byte[] testData = entry.getValue(); final String expected = entry.getKey(); final String actual = StringUtils.toHexString(testData); assertEquals(expected, actual); } } }
Слайд 18
Для того, чтобы запустить данный тест в командной
строке необходимо ввести >java -cp .;d:\distribs\java\junit-4.11.jar;
Слайд 19
Запуск теста. Запуск теста можно сконфигурировать с помощью @RunWith.
При этом класс, указанный в аннотации должен наследоваться от
Runner. Рассмотрим различные “запускалки” JUnit4 — предназначен для запуска JUnit 4 тестов. JUnit38ClassRunner предназначен для запуска тестов, написанных с использованием JUnit 3.
Слайд 20
Categories — попытка организовать тесты в категории(группы). Для
этого тестам задается категория с помощью @Category, затем настраиваются
запускаемые категории тестов. Это может выглядеть так: public class StringUtilsJUnit4CategoriesTest extends Assert { //... @Category(JUnit4TestSuite.class) @Test public void testIsEmpty() { //... } //... }
public class JUnit4TestSuite { } Рассмотрим пример использования категорий в тестах Пусть имеется класс public class JavaTests { public int factorial(int n){ if(n==0) return 1; else { return n*factorial(n-1); } } } Необходимо в нем протестировать метод factorial.
Слайд 22
Первый класс с тестами @Category({IShow.class}) public class FooTest {
JavaTests js; @Before public void initObject(){ js=new
JavaTests(); } @Test public void thisAlwaysPasses() { System.out.println("FooTest-0"); assertTrue(js.factorial(3)==6); } @Test public void thisAlwaysPasses2() { System.out.println("FooTest-2"); assertTrue(js.factorial(4)==24); } }
Слайд 23
Другой класс с тестами @Category({IShow.class}) public class FooTest1 {
JavaTests js; @Category({IShow.class}) @Before public
получим JUnit version 4.11 I..FooTest1-0 I.FooTest-2 .FooTest-0
Time: 0,009
OK (4 tests)
Слайд 25
Parameterized — позволяет писать параметризированные тесты. Для этого
в тест-классе объявляется статический метод возвращающий список данных, которые
затем будут использованы в качестве аргументов конструктора класса. @RunWith(Parameterized.class) public class StringUtilsJUnit4ParameterizedTest extends Assert { private final CharSequence testData; private final boolean expected; public StringUtilsJUnit4ParameterizedTest( final CharSequence testData, final boolean expected ){ this.testData = testData; this.expected = expected; }
Слайд 27
Theories — чем-то схож с предыдущим, но параметризирует
тестовый метод, а не конструктор. Данные помечаются с помощью
@DataPoints и @DataPoint, тестовый метод — с помощью @Theory. Тест использующий этот функционал будет выглядеть примерно так:
@RunWith(Theories.class) public class StringUtilsJUnit4TheoryTest extends Assert {
Слайд 28
@DataPoints public static Object[][] isEmptyData = new Object[][]
{ { "", true }, { " ", false
}, { "some string", false } };
@DataPoint public static Object[] nullData = new Object[] { null, true }; @Theory public void testEmpty(final Object... testData) { final boolean actual = StringUtils.isEmpty((CharSequence)testData[0]); assertEquals(testData[1], actual); } }
Слайд 29
Рассмотрим пример. Класс MathFunc оставим без изменений. Класс
TestClass имеет вид import org.junit.runner.*; import org.junit.Assert; import org.junit.experimental.theories.*; import org.junit.*;
@RunWith(Theories.class) public
class TestClass extends Assert{
public TestClass() { }
@Test public void testFactorialNull() { MathFunc math = new MathFunc(); assertTrue(math.factorial() == 1); }
Слайд 30
@DataPoints public static int[][] Data = new int[][] {{5,
120}};
@Theory public void testFactorialPositive(final int[] obj)
{ MathFunc math = new MathFunc(obj[0]); assertTrue(math.factorial() == obj[1]); }
@Test public void testPlus() { MathFunc math = new MathFunc(45); assertTrue(math.plus(123) == 168); } }
Слайд 31
Запуск теста будет иметь вид: >java –cp .;junit-4.92b2.jar org.junit.runner.JUnitCore
TestClass На экране Time: 0.015 OK(3 tests)
Слайд 32
Пример использования @DataPoint Пусть имеется класс public class JavaTests
{ public int factorial(int n){
if(n==0) return 1; else { return n*factorial(n-1); } } } Тестирующий класс имеет вид:
Слайд 33
RunWith(Theories.class) public class FooTest { JavaTests js;
@Before public void initObject(){ js=new JavaTests();}
@DataPoint public static int nData=2;
@Theory public void thisAlwaysPasses(int n) { assertTrue(js.factorial(n)==2); } }
Слайд 34
Журналирование Log4j При небольшом приложении вполне хватет возможностей System.out.println(), но
по мере увеличения и усложнения приложения его возможностей уже
нехватает. В частности нельзя (или затруднительно) сделать с помощью System.out.println(): 1) управление логгированием: отключить логгирование одних сообщений, и включить логгирование других
и т.п.
3) вывод дополнительной информации о сообщении: время события,
место события, контекст
4) форматирование вывода Для решения этих проблем были созданы системы логгирования. Две наиболее популярные это Log4j от Apache и Java Logging API входящее в состав JDK 1.4 и старше. Рассмотрим пример использования Log4j:
public static void main(String[] args) throws Exception{ BasicConfigurator.configure(); logger.info("Hello world!"); logger.error("Error!", new Exception("An exception")); } }
Слайд 37
Для запуска данного приложения нужен пакет log4j-1.2.16.jar. На экране
получим:
0 [main] INFO ru.vingrad.log.Test - Hello world!
0 [main] ERROR ru.vingrad.log.Test - Error! java.lang.Exception: An
exception
at Test.main(Test.java:12)
Базовым классом через которое и будет идти все логгирование является org.apache.log4j.Logger. Для получения логгера используется статический метод getLogger() куда в качестве параметра надо передать имя этого логгера.
Слайд 38
Каждый логгер имеет уникальное имя, и вызов getLogger() с одним
и тем же именем вернет один и тот же
логгер. Логгер синхронизирован и его можно свободно использовать в многопоточной среде. Существует корневой логгер, являющийся родительским для всех остальных, получить его можно: Logger.getRootLogger(). Важным фактом является то, что если логгер не сконфигурирован индивидуально, то он будет использовать настройки своего родительского логгера.
Слайд 39
Т.е. можно сконфигурировать только корневой логгер, а все
логгеры будут использовать его настройки. Логгер может писать сообщения разных
уровней (org.apache.log4j.Level). Уровни упорядочены по старшинству (в порядке убывания): FATAL, ERROR, WARN, INFO, DEBUG, TRACE. Уровни FATAL, ERROR, WARN предназначены для сообщений об ошибках, разной степени серьезности, INFO информационные сообщения, DEBUG - отладочные, TRACE - очень подробная отладочная информация.
Слайд 40
Когда конфигурируется система логгирования то указывается сообщения какого
уровня надо писать в лог. В лог будут писаться сообщения
этого уровня и выше, т.е если система настроена на уровень INFO то будут писаться сообщения с уровнями FATAL, ERROR, WARN, INFO. Плюс еще есть спец уровни ALL и OFF, которые предназначены для включения/выключения записи всех сообщений.
Слайд 41
Следующая составляющая системы логгирования это - аппендер (org.apache.log4j.Appender).
Аппендер - это класс который занимается непосредственно записью сообщений. org.apache.log4j.Appender это
интерфейс, но у него есть реализации для записи сообщений в консоль, файл, БД, e-mail и т.д. Так же у аппендера можно установить фильтры (org.apache.log4j.spi.Filter) для фильтрации сообщений. И форматер сообщений (org.apache.log4j.Layout) для форматирования выводимых сообщений.
Слайд 42
Рассмотрим процесс записи логов: Вызываем logger.info("Hello world!")
2. Происходит проверка
уровня логгирования для данного логгера, если данному логгеру не
был явно задан уровень, то тогда проверка осуществляется для его родителей. Если уровень логгера выше уровня сообщения, то оно отбрасывается и запись его не происходит. В нашем случае корневой аппендер сконфигурирован на уровень DEBUG а у сообщения уровень INFO, т.е. уровень логгера ниже уровня сообщения и оно проходит проверку.
Слайд 43
3. Далее сообщение передается аппендерам установленным для данного
логгера (если есть).
4. Если свойство additivity установлено в true (по умолчанию оно установлено),
то сообщение так же передается родительским логгерам.
5. Аппендер получив сообщение проверяет его установленными фильтрами (если есть). Если сообщение прошло фильтры оно форматируется и записывается в лог.
Слайд 44
Рассмотрим конфигурацию логгеров. Для конфигурирования Log4j используются файлы конфигурации
log4j.xml и log4j.properties. Далее рассмотрим конфигуратор log4j.xml Cоздаем в папке с
исходниками файл log4j.xml:
SYSTEM "log4j.dtd">
(файл log4j.dtd можно найти внутри log4j.jar)
class="org.apache.log4j.ConsoleAppender">
value="%d{ISO8601} [%5p] %m at %l%n"/>
Слайд 46
CONSOLE-DEBUG имя аппендера, по этому имени он будет упоминаться
в этом конфиге. org.apache.log4j.ConsoleAppender - имя класса аппендера.
-
устанавливает параметр аппендера который определяет куда писать лог
Слайд 47
Аналогично конфигурируется аппендер для ошибок
class="org.apache.log4j.ConsoleAppender">
class="org.apache.log4j.PatternLayout">
value="%d{ISO8601} [%5p] %m at %l%n"/>
class="org.apache.log4j.varia.LevelRangeFilter">
разница в том, ошибки будут писаться в System.err.
Слайд 49
Теперь сконфигурируем логгеры. Предположим что используется Hibernate и
необходимо видеть только сообщения об ошибках и писать их
только в консоль но не файл.
Слайд 50
Но в то же самое время, необходимы отладочные
сообщения в org.hibernate.SQL (где пишутся выполняемые Hibernate SQL запросы).
value="DEBUG"/>
Слайд 51
Для всех остальных категорий включаем уровень DEBUG и
запись в консоль и файл
ref="LOG-FILE-APPENDER"/>
Слайд 52
Протестировать данный xml файл можно следующим кодом:
import org.apache.log4j.Logger; import
org.apache.log4j.BasicConfigurator;
public class Test { private static Logger logger =
Logger.getLogger(Test.class); public static void main(String[] args) throws Exception { logger.debug("Inside main()"); logger.info("Hello world!"); logger.error("Error!", new Exception("An exception")); Logger hibernateGeneral = Logger.getLogger("org.hibernate"); hibernateGeneral.debug("Starting Hibernate"); Logger hibernateSql = Logger.getLogger("org.hibernate.SQL"); hibernateSql.debug("select * from my table"); hibernateGeneral.error("Hibernate error"); } }
Слайд 53
Содержимое файла app.log имеет вид: 2011-06-10 01:47:28,968 [DEBUG] Test
Inside main() at Test.main(Test.java:9) 2011-06-10 01:47:28,968 [ INFO] Test Hello
world! at Test.main(Test.java:10) 2011-06-10 01:47:28,968 [ERROR] Test Error! at Test.main(Test.java:11) java.lang.Exception: An exception at Test.main(Test.java:11)
Слайд 54
Рассмотрим пример: import org.apache.log4j.Logger; import org.apache.log4j.FileAppender; import org.apache.log4j.SimpleLayout; import org.apache.log4j.Level; import java.io.IOException; public class
DemoLog { static Logger logger = Logger.getLogger(DemoLog.class); public static
"argument " + n +" less then zero"); logger.debug("Argument n is " + n); int result = 1; for (int i = n; i >= 1; i--) result *= i; logger.info("Result is " + result); return result; } При этом в корне проекта должен находиться конфигурационный файл "log4j.xml" со следующим содержимым:
Слайд 58
Maven Жизненный цикл Maven имеет вид:
validate — проверяет корректность
метаинформации о проекте compile — компилирует исходники test — прогоняет тесты
классов из предыдущего шага package — упаковывает скомпилированые классы в удобноперемещаемый формат (jar или war, к примеру) integration-test — отправляет упаковынные классы в среду интеграционного тестирования и прогоняет тесты verify — проверяет корректность пакета и удовлетворение требованиям качества install — загоняет пакет в локальный репозиторий, откуда он (пекат) будет доступен для использования как зависимость в других проектах deploy — отправляет пакет на удаленный production сервер, откуда другие разработчики его могут получить и использовать
При этом все шаги последовательны. И если, к примеру, выполнить $ mvn package, то фактически будут выполнены шаги: validate, compile, test и package. Таким образом использовать мавен довольно просто. Написали код, выполнили mvn test и можно работать дальше, убедившись что код не содержит синтаксических и логических ошибок.
Слайд 59
При этом все шаги последовательны. И если, к
примеру, выполнить $ mvn package, то фактически будут выполнены
шаги: validate, compile, test и package. Таким образом если написан код, то можно выполнить mvn test для проверки. Maven конфигурируется файлом pom.xml, который может содежать блок . В нем описывается какие библиотеки нужны проекту для полноценного функционирования. На шаге validate мавен проверяет удовлетворены ли зависимости и если нет, то скачивает из удаленный репозиториев необходимые компоненты в локальный репозиторий.
Слайд 61
Плагины под Maven maven-archetype-plugin Плагин maven-archetype-plugin предназначен для того чтобы
по существующему шаблону создавать новые проекты. Создать проект с помощью
maven-archetype-plugin достаточно просто - достаточно набрать: mvn archetype:generate
Слайд 62
maven-compiler-plugin Компилятор - основной плагин который используется практически во
всех проектах. Он доступен по умолчанию, но практически в
каждом проекте его приходится переобъявлять т.к. настройки по умолчанию не очень подходящие.
Пример использования: org.apache.maven.plugins maven-compiler-plugin 2.0.2 1.6 1.6 UTF-8
В этом примере в кофигурации используется версия java 1.6 (source - версия языка на котором написана программа; target - версия java машины которая будет этот код запускать) и указано что кодировка исходного кода программы UTF-8.
который запускает тесты и генерирует отчёты по результатам их
выполнения. По умолчанию отчёты сохраняются в ${basedir}/target/surefire-reports и находятся в двух форматах - txt и xml. Тесты можно писать используя как JUnit так и TestNG. по умолчанию запускаются все тесты с такими именами "**/Test*.java" - включает все java файлы которые начинаются с "Test" и расположены в поддиректориях. "**/*Test.java" - включает все java файлы которые заканчиваются на "Test" и расположены в поддиректориях. "**/*TestCase.java" - включает все java файлы которые заканчиваются на "TestCase" и расположены в поддиректориях. Пропустить выполнение тестов можно true
или mvn install -DskipTests чтобы пропустить ещё и компиляцию тестов: mvn install -Dmaven.test.skip=true
Слайд 64
maven-javadoc-plugin Плагин maven-javadoc-plugin предназначен для того чтобы генерировать докуметацию
по исходному коду проекта стандартной утилитой javadoc. maven-site-plugin Плагин maven-site-plugin
предназначен для того чтобы легко создавать сайт проекта. В директории Вашего проекта наберите mvn site И мавен автоматически сгенерирует сайт по нему. Сгенерированные файлы будут лежать в директории target/site.
Слайд 65
maven-checkstyle-plugin Плагин проверяет стиль и качество исходного кода. Из наиболее
часто используемых и простых проверок: наличие комментариев размер класса не
более N строк в конструкции в try-catch, блок catch не пустой. не используется System.out.println(.. вместо LOG.error(..
Слайд 66
Подключить плагин можно следующим образом:
org.apache.maven.plugins maven-checkstyle-plugin
2.7
........... после этого можно запустить проверку кода: mvn checkstyle:check Позволяет создавать собственный набор правил.
Слайд 67
findbugs-maven-plugin findbugs-maven-plugin плагин для автоматического нахождения багов в проекте.
Принцип действия плагина основан на поиске шаблонов ошибок. Код
проекта проверяются на часто встречаемые ошибки, неправильное использование API и конструкций языка. Пример настройки данного плагина:
Слайд 71
Создание проекта в Maven mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=com.mycompany.app
-DartifactId=my-app Для создания,например web-приложения mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp Файл
проекта для web приложения будет xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> 4.0.0 ua.unicyb.app webapps war 1.0-SNAPSHOT webapps Maven Webapp http://maven.apache.org junit junit 3.8.1 test
для запуска кода, под управлением виртуальной машины Java (JVM),
который написан на языках С/С++ или Ассемблера, и скомпонован в виде динамических библиотек, позволяет не использовать статическое связывание. Это даёт возможность вызова функции С/С++ из программы на Java, и наоборот.
Слайд 77
Рассмотрим пример использования JNI. Имеется следующий Java проект package
javaapplication114; public class TestNativeClass { private static int
![import junit.framework.*;import junit.textui.*;public class Main{ public static void main(String[] args) {](/img/tmb/15/1443594/c2be30bb4e77073a67d2a413db8f56a9-720x.jpg "Тестирование. Пакет JUnit. Java. (Лекция 24)")
![@DataPoints public static Object[][] isEmptyData = new Object[][] { {](/img/tmb/15/1443594/d1e0e9b7ddb142acdc4c57c4d85cf868-720x.jpg "Тестирование. Пакет JUnit. Java. (Лекция 24)")
![@DataPointspublic static int[][] Data = new int[][] {{5, 120}}; @Theory public](/img/tmb/15/1443594/150e03c94961309a15af1fba44fe2062-720x.jpg "Тестирование. Пакет JUnit. Java. (Лекция 24)")
![Для запуска данного приложения нужен пакет log4j-1.2.16.jar.На экране получим: 0 [main] INFO ru.vingrad.log.Test - Hello](/img/tmb/15/1443594/f18faeea121cc1c562ac44fcb50a3bed-720x.jpg "Тестирование. Пакет JUnit. Java. (Лекция 24)")
![Содержимое файла app.log имеет вид:2011-06-10 01:47:28,968 [DEBUG] Test Inside main() at Test.main(Test.java:9)2011-06-10](/img/tmb/15/1443594/41cd3b43cb423f99f2ef0cce2b138585-720x.jpg "Тестирование. Пакет JUnit. Java. (Лекция 24)")
