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

ВСЕ ЧТО Я ПИШУ ПО ЭТОЙ ТЕМЕ, ЛИШЬ МОЕ СКРОМНОЕ ЛИЧНОЕ МНЕНИЕ. Я УВАЖАЮ И ПРИСУШИВАЮСЬ К МНЕНИЮ ДРУГИХ ЛЮДЕЙ, КОТОРЫЕ ЖЕЛАЮТ РАЗВИТИЯ ДАННОГО ПРОЕКТА. ЕСЛИ У ВАС ЕСТЬ ИДЕИ ПО СОВЕРШЕНСТВОВАНИЮ ДАННОЙ СИСТЕМЫ, ТО ПОЖАУЙСТА, НЕ МОЛЧИТЕ. ВСЕ ПРЕДЛОЖЕНИЯ БУДУТ РАССМОТРЕНЫ И ПРИНЯТЫ ДОЛЖНЫМ ОБРАЗОМ. (это я так, на будущие).

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



Да, у меня тоже есть в сомнения по этому вопросу. Просто на первый раз мне показалось, слишком утомительным идея динамического формирования интерфейса. (... ? Хотя его ведь можно сделать не динамический строгий интерфейс, например на основе таблиц настоек ?...). Я когда думал на тему компонентов, в голову так и напрашивалась JavaBeans модель.

Что каксается графического интерфейса настройки теста, то это самая настоящая эксерементальная модель. Возможно будет другой подход в настройке, вообще без GUI.
Вообще с настройкой тестов и моделью взаимодействия менеджер тест есть большие вопросы. Этот момент придется еще не раз обсудить, поскольку он весьма важен, и пока точно не определен. Определение порядка взаимодействия компонентов - важная часть разработки системы.

Я еще раз все перепродумаю, и попробую написать небольшой пример на эту тему.

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

Это сообщение отредактировал(а) MoonCat - 14.2.2006, 21:11

Если небольшой, то можно прикрепить файл через форму ответа (по кнопке "Ответить", она среди кленовых листочков).

А если большой (более 50К), то вышли мне я прикреплю.

Хм. Если тест проводится с собственным гуем, это повлияет на скорость, имхо, весьма значительно.
В .NET можно было бы использовать компонент PropertyGrid для задания свойств теста перед его выполнением, а тут вроде аналогов нет..
Добавлено @ 00:58
Кстати, предлагаю запускать тесты в отдельном потоке от гуя. А то тормозить страшно будет при объемных тестах.

Больше 50k, чиркни свой майл пожалуйста, я вышлю.



А как это повлияет на скорость теста? ИМХО, JVM придется только памяти выделить под компонент настройки и все.
Тест действительно будет выполняться в отдельном потоке, возможно, приоритет которого можно даже будет настроить.

Вообщема так, мое ИМХО

ГУЙ конечно ресурсы будет жрать и не только память, самое противное это перерисовка компонент. Она может неожиданно возникать и портить нам всю малину, в виде всплесков потребления процессорных ресурсов. Соответсвенно результаты могут плавать, что не есть хорошо. Да и для повторения теста на другой машине придется описывать какие параметры, куда забиваются. Плюс для какждого теста писать свой конфигуратор. Из-за всего этого мне и не нравится идея с ГУЕМ.

Я предлагаю работать, через конфигурационные файлы. За образец я бы взял конфигурационные файлы log4j. Маленький примерчик для тех кто не знаком:

Здесь мы указываем имя класса: org.apache.log4j.DailyRollingFileAppender, который надо создать, и имя property которые надо установить: File, Append, DatePattern и значения для них. Плюс общие настройки. Таким макаром можно один раз написать систему тестирования и больше ее не переписывать. И проблем с конфигурированием тоже нет, переслать конфигурационный файл, пара пустяков.

Выполнив настройку, GUI можно закрыть, и проблема перерисовки отпадет сама собой, ведь
его не будет на экране. Меня в GUI настроики смущает, лишь то, что стилистика не будет выдержена и то что люди могут полениться писать GUI.



Интересная идея! Но сожалению я плохо понимаю как это все работает. Было очень инересно прочитать продолжение этой идеи и (если можно) с ответами на эти вопросы:

1) Как определить какие настройки поддерживает тест. (Включая типы значений и допустимые
диапазоны значений)?
2) Как создать графический настройщик для определенного теста?
3) Как проверить корректность настройки?

P.S.
GUI настройщик легко решает все эти проблемы, требуя лишь немного больше память, которую кстати можно ухитрившись освободить, но придется разделить Компонент Тест на ВИД и МОДЕЛЬ,
а Вид освобождать после настройки. Это добавит еще гибкости. И кстати ничто не мешает сохранять настройки теста в файл самостоятельно, а потом загаружать их на другой машине.
Вообще, используя GUI настройщик для каждого класса, мы поддерживаем чистый компонентный подход в разработке проекта. Поддерживаем идею, когда каждый может написать чать Системы Тестирования JVM, и не только закодировать тетст, но и добавить к нему свое оформление, которое придаст ему иникальности.

Я легко откажусь от своей идеи с GUI настройщиком, если будет то, что сможет по гибкости и простоте его заменить.........

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

Всмысле сначало настраиваем ряд тестов, сохраняем сценарий в файле xml, освобождаем память
от ненужных GUI и выполняем тест только на рабочих тест-компонентах?

Одна проблема безгуевого решения -- невозможность узнать прогресс. Как вариант -- перед стартом теста действительно показывать некий гуй, определенный компонентом, а потом попросту отображать прогрессбар, который периодически обновляется. Прогрессбар берет свое значение от некой функции GetCompletedPercentage, которую обязан реализовать каждый тест.

Гуй в пень.

Могикане считали, что нетерпеливость простительна женщинам, но не мужчинам, подождут

Disclaimer: поскольку MoonCat не может прикреплять большие файлы, это делаю я, весь последующий текст, это его комментарий к коду:

============8<============8<============8<============8<============8<============

Вот небольшой пример на тему раннее изложенных мною мыслей.
Программа с MDI интерфейсом, имеет 3 основных части:
1) Главное окно.
2) Менеджер (загрузчик) плагинов. ( Отображает список доступных плагинов и загружает их в Контейнер настройки плагина ).
3) Контейнер настройки плагина. (выполняет интерфейс настройки плагина).

Вы можете компилировать исходники любым удобным для Вас способом.
К сообщению прикреплен архив с 2 проектами в формате NetBeans 5.0, если у кого стоит такой, то можно прямо им и рулить. А можно все ручками.

Первый проект - это Сисема Выполнения Тестов, второй - плагин, на примере сортировки. Ознакомьтесь со структурой файлов в архиве distrib.zip. После того как сами скомпилируете файлы воссоздайте такую же структуру. Если не хотите компилировать сами, то запускайте готовый, но он работать будет на jre1.5.0_06.

Вот еще краткие замечания по сборке:
Функционально программа состоит из двух частей: Система тестирования (Poseidon.jar + lib/swing-layout-1.0.jar) и плагин ( папка lib/ru/...).

Вот состав архива Poseidon.jar после компиляции:
META-INF\MANIFEST.MF
frames\MainFrame$1.class
frames\MainFrame.class
frames\ManageInternalFrame$1.class
frames\ManageInternalFrame$2.class
frames\ManageInternalFrame.class
frames\SettingsContainer$1.class
frames\SettingsContainer$2.class
frames\SettingsContainer$3.class
frames\SettingsContainer.class
ru\vingrad\java\poseidon\PoseidonTest.class

В манифесте (META-INF\MANIFEST.MF) параметр "Class-Path: lib/ /lib/swing-layout-1.0.jar" - должен выгладеть так (но без кавычек), чтобы программа нашла расположенные там плагины и библиотеки. Гланый класс - MainFrame.class.

Папка lib должна выглядеть так:
ru\vingrad\java\poseidon\plugins\sort\SortLibrary.class
ru\vingrad\java\poseidon\plugins\Sort.class
ru\vingrad\java\poseidon\plugins\Sort$1.class
ru\vingrad\java\poseidon\plugins\Sort$2.class
ru\vingrad\java\poseidon\PoseidonTest.class

Здесь
PoseidonTest.class - Интрефейс, который должен поддерживать каждый плагин.
Sort.class - Плагин, реализующий интерфейс PoseidonTest и наследованный от JPanel
SortLibrary.class - Библиотека алгоритмов сортировки, которую использует плагин Sort.

Когда скомпелируете плагин, добавьте его файлы, а вернее все файлы из папки ru/... в папку lib/plugins/ , которая находится в одной папке с Poseidon.jar. Запускайте Poseidon.jar из папки в которой он находится, если хотите чтобы все заработало.

(Кстати, Все исходки прокоментированны. На все вопросы постараюсь ответить.)

Что будет после запуска программы.
Появится главное MDI окно, в котором будет окошко менеджера тестов. Лист в окне менеджера тестов должне содержать один элемент - Sort. Выберите и загрузите его. Если все настроено правильно, то загрузится контейнер настроек, с элементом настройки теста Sort. Тест можно будет настроить и выполнить. Поэспериментируйте с программой.

Хочу отметить что это всего лишь пример! Неуклюжий, неоптимизированный, неотлаженный и вообще немного дурацкий пример, который все же позволяет продемонстрировать идею многокомпонентного приложения.

Прикрепленные файлы: distrib.zip, Poseidon.zip, Sort.zip.

============8<============8<============8<============8<============8<============

Я рекомендую обратить особое внимание не интерфейс, который является базовым для всех плагинов (PoseidonTest). Возможно будут мысли разбить его на несколько или добавить в него еще какие нибудь методы, your are welcome

Ваши альтернативы ???