[Автоматизация. : Поиск категории по названию. : Тест-элемент.]
{09:54}
Название задания не изменил ещё, хотя уже договорился сам с собой, что это никакой не тест-элемент... Теперь я рассматриваю и реализую тест-ядро.
Так и не определился ещё, в каком виде будет выдавать результат тест-ядро в моей системе. Варианта два: булевое значение и сообщение об исключительной ситуации.

[Автоматизация. : Тест-ядро. : Спецификация.]
{10:02}
Результат выполнения тест-ядра может иметь только два значения: успех и неудача. Каким образом сообщать о результате?
Вариант первый. В случае удачного выполнения никаких дополнительных действий не совершается. В случае неудачного исхода генерируется сообщение об исключительной ситуации. Обрабатывать эту ситуацию можно непосредственно в тест-элементе или передавать вызывающему методу, в данном случае, Менеджеру Тест-ядер. Здесь нужно подумать о том, чего я жду от Системы, как она должна реагировать на происшедшее. (Посмотрел в словаре. "Произошедший" и "происшедший" - правильные равноправные слова.)
Тест-ядро не должно само обрабатывать исключение. Это слишком большая для него ответственность. Если взвалить её на него, то каждому тест-ядру, к примеру, придётся общаться с Менеджером Логирования, то есть ещё одним элементом не его уровня. Кроме того, у тест-ядра нет достаточных знаний, чтобы принять важное решение, например, о перенаправлении логического потока. В общем, задача тест-ядра - сообщить Менеджеру Тест-ядер о случившемся и передать ему всю имеющуюся информацию, а он уже пускай кумекает, как быть. В связи с этим вариант второй - возвращение результата выполнения в виде булевого значения - видится недостаточным ввиду информационной скудности. Потому принимаю такое решение.
["Результат выполнения тест-ядра возвращается вызывающему объекту в виде отсутствия информации в случае удачного выполнения и в виде информации об исключительной ситуации в случае неудачного выполнения."]

[Автоматизация. : Поиск категории по названию. : Тест-элемент.]
{10:34}
Нужно переделать тест-ядро так, чтобы он использовал условие, способное сгенерировать исключение в случае его невыполнения.
Таким образом, Менеджер Тест-ядер получает исключение и может предпринимать какие-то действия. А вот как он сообщает о результате тесту?

[Автоматизация. : Тест. : Спецификация.]
{10:50}
Если тест обращается к тест-ядру, то в каком виде предпочтительно вовращать результат выполнения тест-ядра?
Обращение к тест-ядру происходит для проверки какого-то условия. Если условие подразумевает только два вида ответа - "Да" и "Нет", - это подразумевает разветвление логики по двум направлениям. Использовать для этого исключение как-то странно. В принципе, тесту всё равно, сработает условие или нет. Он просто задаёт вопрос и ожидает на него один из известных ему ответов. Неизвестных ответов, неожиданных, каким является исключение, ему не требуется.
["Результатом обращения теста к тест-ядру посредством Менеджера Тест-ядер является булевое значение."]

[Автоматизация. : Поиск категории по названию. : Тест-элемент.]
{11:55}
Всё, тест-ядро готово. Реализованы условия проверки и для успеха, и для неудачи. Возврат результата - в соответствии со спецификацией. Протестировано.

[Автоматизация запуска тестов]
{12:20}
А имеется ввиду следующее - запуск моих тестов Женькиной системой Continuous Integration. Для этого требуется, чтобы мои тесты были собраны в JUnit Suite. Вот этим сейчас и займёмся.
Главная загвоздка в том, что мои тесты не имеют к JUnit никакого отношения. Тест-ядра используют некоторые методы JUnit-библиотеки - и только. Теперь нужно придумать, как заставить JUnit выполнять мои тесты, причём сами тесты я никак изменять не хочу.
{13:32}
Что ж, выполнить тест под управлением JUnit получилось. Для этого пришлось сделать ещё один менеджер, пока назвал его JUnitManager, в котором прописываются все тесты, доступные для выполнения. Конечно, это только ссылки на реальные тесты. Кроме того, в класс теста добавил статик-поле, содержащее имя теста.