Итак, исходные данные:
имеется приложение на Java, стандартная 3х-уровневая система (складской учет).
Встал вопрос о регресионном тестировании, т.е. об определении того, ничего ли из работавшего раньше не "упало" при добавлении нового функционала и минимизации времени на тестирование этого самого нового функционала.
Изначально JUnit не использовался, теперь же, вероятно, именно он и нужен.
Только вот нет идей с чего начать. Писать тесты для уже существующих классов?
Никто с подобной ситуацией не сталкивался?

Благодарю.

Мне тоже весьма интересна тема тестирования 3-уровневого приложения и мы примерно в такой-же ситуации.

Насколько я понимаю, JUnit был создан для изолированного тестирования отдельных кусков. Теория учит, что с этого и надо начинать. Однако ясно, что существуют баги, которые проявляются во взаимодействии. Они и представляют наибольшую опасность.

Делать примитивные тесты для отдельных классов задним числом конечно принесет пользу, но это может и не оправданно. Вот создавать новые классы может и имеет смысл уже следуя этой концепции. Если же система уже функционирует, то более актуальным представляется (в нашем случае) создание средства ежедневного комплексного мониторинга. И возможно имеет смысл использовать JUnit как API для организации серии комплексных тестов. С другой стороны в JUnit надо разбираться и следовать предложенному стандарту (как и с любым другим инструментом, созданным с благой целью облегчить и ускорить девелопмент). Четкого мнения пока нет.

Это сообщение отредактировал(а) COVD - 14.4.2006, 17:05

Да, в общем-то и интересует именно средство для "ежедневного комплексного мониторинга".
Есть такая штука как CruiseControl, которая позволяет автоматически делать сборки (ant'om) и тестировать их. С использованием того же JUnit.

Похоже, мало кто при разработке использует автоматизированное тестирование.

Есть неплохой софт от AGITA SOFTWARE. Правда софт платный и стоит не мало. Однако крупные фирмы вполне могут себе позволить это.

JUnit прост как грабли. это скорее идея нежели фреймфорк. что-то подобное можно написать самостоятельно за тройку дней. Существуют масса "потомков" всякие JSPUnit-ы JNDIUnit-ы и т.п.

А вот ХР-ая идея автоматических изолированных тестов это вещ. это делать надо. это скажется очень здорово на стабильности и качестве вашей программы даже если вы напишите тесты для 10% своей системы. и не важно как вы эти тесты будете писать будет это JUnit или вы напишите собсвтенный фреймфорк. тут главное решиться.

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

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

В общем, когда ОП вышел на промышленные масштабы работы, эта система позволила избежать кучи проблем :-)