Здесь я пытаюсь адаптировать процесс автоматизации модульного тестирования pde [1] для обработки нескольких наборов тестов.В статье используется org.eclipse.jdt.internal.junit.model.ITestRunListener2, который не может обрабатывать несколько наборов тестов.Я думаю об использовании org.eclipse.jdt.junit.TestRunListener вместо этого.
Я попытался преобразовать включенную реализацию org.eclipse.jdt.internal.junit.model.ITestRunListener2 для реализации junit.runner.TestRunListener, так как метод testRunStarted () включает параметр имени набора тестов, но не смогнайдите любой пример того, как адаптировать org.eclipse.jdt.internal.junit.model.RemoteTestRunnerClient к его использованию (я не уверен, даже если протокол результатов теста PDE его поддерживает).
- Будетс помощью JUnitCore.addTestRunListener (слушатель) сможет заменить весь подход тест-результаты-слушатель?нет необходимости запускать тесты удаленно.
- Любые другие предложения о том, как добавить поддержку нескольких пакетов в [1]?
[1] http://www.eclipse.org/articles/article.php?file=Article-PDEJUnitAntAutomation/index.html
Здравствуйте, это OP, не удалось добавить коммент. Ответ Пола Вебстера, поэтому я публикую это.
С RemoteTestRunnerClient дело в том, что он делегирует уведомления своим слушателям согласнок протоколу, определенному в org.eclipse.jdt.internal.junit.runner.MessageId, с сообщениями, читаемыми из сокета TCP.Проблема заключается в том, что сообщения TEST_RUN_START / END не содержат имя набора, в результате чего все тесты связаны с одним и тем же набором.
Я взглянул на Eclipse Test Framework при настройке автоматизированной среды тестирования, но не смог найти веских причин, чтобы поддержать его по сравнению с подходом, предложенным в статье.Я не уверен, но я думаю, что причина, по которой статьи не использовали ETF, заключалась в недостаточной поддержке агрегации результатов тестирования.Теперь я могу оценить, какие наборы должны запускаться через файлы test.xml, поскольку в настоящее время я использую аргумент -classnames, передаваемый приложению org.eclipse.pde.junit.runtime.coretestapplication.Я не возражал бы рассмотреть возможность перехода на ETF, но хотел бы заранее иметь веские причины для этого.
Суть в том, что при моей настройке, выполняющей 99% от требуемой, я предпочел бы быстрый и грязный обходной путь, а не полное преобразование тестовой системы.