Pull to refresh

Comments 13

никогда нельзя быть уверенным, в какой очередности пройдут тесты
У вас проект антом собирается?
Мне казалось, что это проблема на уровне jUnit. Сборщику мы просто говорим выполнить класс.
С антом, к счастью, не часто приходилось работать, поэтому не могу ничего сказать. В мавене выполнением тестов занимается отдельный плагин. Если я правильно помню, тесты в классе он выполняет в алфавитном порядке. В 7-й версии TeamCity, кстати, появилась возможность фейлить билд если определенный текст встречается в билд логе — вам могло бы быть полезно =)
Дык в этом-то и проблема — в TeamCity есть бага (или недоделка) из-за которой он не воспринимает сервисные команды из билд лога тестов. В начале поста есть ссылка на багтрекер JetBrains`а. А что касается порядка тестов, то мне кажется иногда бывает очень полезно сделать порядок тестов на свое усмотрение.
Мне всегда казалось, что результат выполнение одного unit теста ни в коем случае не должен зависеть от результата выполнения предыдущего. Я ошибаюсь?
Если Вы имеете ввиду относительно этой модели, то здесь оно и не зависит. Класс тестов может содержать общие поля. Такие, как url приложения, логин / пароль и т.п. Если же в ходе тестового метода меняются какие-то общие поля тестового класса, то можно добавить что-то типа:

@Before
public void clear()
{
     //Очищаем общие поля
}


Хотя это конечно будет не правильно. ИМХО каждый тестовый метод должен работать только в самом себе и не менять ничего общего.
Я на самом по поводу этого:
Например, никогда нельзя быть уверенным, в какой очередности пройдут тесты.

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

Все это реализовано в другом фреймворке: TestNG. Чтобы не заниматься поддержкой собственных «велосипедов» вам стоит взглянуть на него.

Что касается TeamCity, то в его задачи не входит поддержка порядка исполнения тестов. Зато входит необходимость как можно раньше сообщить об упавших/исправленных тестах. Для этого имеет смысл выполнить падавшие недавно тесты как можно раньше, т.е., изменить порядок исполнения.
Only those users with full accounts are able to leave comments. Log in, please.