Я сталкивался со споком на груви и был просто «под впечатлением». Очень зачетный фреймворк. Но на моем текущем проекте почему-то никто не разделил моей радости. Возможно если бы больше людей о нем узнали, он бы лучше приживался в проектах.
Ну изначальный смысл либы был именно в ситуации, когда нужно переключиться на другой фреймворк, при этом убрав старый. Чтобы в проекте не получилось 100500 тестовых фреймворков. Если нет проблемы в том, чтобы докинуть пару-тройку тестовых фреймворков, то эта либа не нужна. Ну разве что в ситуации, когда разработчику хочется писать все тесты в одном стиле.
Даже не знаю, у меня почему-то именно группы сразу пришли на ум, как киллерфича :).
По поводу листенеров, есть вот такое org.junit.runner.notification.RunListener и org.junit.runner.notification.RunNotifier. Я честно говоря с ними не работал, но возможно функционал достаточно похож.
Наверное для них тоже есть смысл добавить поддержку в либу.
Честно говоря я не видел в API testng методы с матчерами. В этом конечно есть небольшая проблема. Многие используют этот функционал junit`а. Но чтобы сделать его в либе, придется выцепить этот код из junit`а.
Да, звучит логично.
Как вариант — фреймворк будет предоставлять полный функицонал обоих. А в случае, если отсутсвует нужная либа, то логировать варнинг о нехватке зависимостей и использовать какие-то стабы для отсутсвующей функциональности. Я правильно понял мысль?
Для быстрого создания первой версии приложения на флэше подходит вот такой BaaS сервис. У них там есть SDK для Flex/Air клиентов и куча разных фич, в том числе запись/проигрывание медиа файлов с сервера.
В этом случае, я имел ввиду немного другое. В моей ситуации (не классических юнит-тестов), мне нужно было запускать Тест3 только в том случае, если прошли Тест1 и Тест2. Используя предлагаемую модель, это сделать очень просто, не запихивая все в один тест.
Если Вы имеете ввиду относительно этой модели, то здесь оно и не зависит. Класс тестов может содержать общие поля. Такие, как url приложения, логин / пароль и т.п. Если же в ходе тестового метода меняются какие-то общие поля тестового класса, то можно добавить что-то типа:
@Before
public void clear()
{
//Очищаем общие поля
}
Хотя это конечно будет не правильно. ИМХО каждый тестовый метод должен работать только в самом себе и не менять ничего общего.
Дык в этом-то и проблема — в TeamCity есть бага (или недоделка) из-за которой он не воспринимает сервисные команды из билд лога тестов. В начале поста есть ссылка на багтрекер JetBrains`а. А что касается порядка тестов, то мне кажется иногда бывает очень полезно сделать порядок тестов на свое усмотрение.
По поводу листенеров, есть вот такое org.junit.runner.notification.RunListener и org.junit.runner.notification.RunNotifier. Я честно говоря с ними не работал, но возможно функционал достаточно похож.
Наверное для них тоже есть смысл добавить поддержку в либу.
Как вариант — фреймворк будет предоставлять полный функицонал обоих. А в случае, если отсутсвует нужная либа, то логировать варнинг о нехватке зависимостей и использовать какие-то стабы для отсутсвующей функциональности. Я правильно понял мысль?
Хотя это конечно будет не правильно. ИМХО каждый тестовый метод должен работать только в самом себе и не менять ничего общего.