Исключить отдельные Методы тестирования JUnit, не изменяя Тестовый класс?
Следуя примеру Huge, это было остротой, которую я должен был на Ubuntu 16 изменить от значка до представления списка:
gsettings set org.gnome.nautilus.preferences default-folder-viewer 'list-view'
6 ответов
Если вы не можете прикоснуться к исходному тесту вообще у вас будут серьезные ограничения. Ваше переопределение звучит как лучший вариант, но с парой изменений:
Создайте тесты Ant, специально исключая суперклассы, чтобы запускались дополнительные классы, о которых вы не знаете.
Вы можете использовать @ Аннотации правила (новое в JUnit 4.7), чтобы узнать, какой тест выполняется, и прервать его (путем возврата пустой реализации утверждения), а не переопределить определенные методы, что дает вам больше гибкости в понимании того, следует ли избегать теста. Единственная проблема с этим методом заключается в том, что вы не можете остановить выполнение методов @Before с помощью этого метода, который может быть медленным. Если это проблема (и вы действительно не можете прикоснуться к тестам), тогда @Ignore в переопределенном методе - единственное, о чем я могу думать.
Если, однако, вы можете прикоснуться к этим тестам, откроются некоторые дополнительные параметры :
Вы можете запустить их с помощью специального средства запуска, указав тег @RunWith в классе. Этот бегун просто передаст выполнение стандартному бегуну (JUnit4.class) в этом проекте, но в вашем проекте (через системное свойство или какой-либо другой механизм) будет проверять имя теста, а не запускать тест. Преимущество этого заключается в том, что он наименее навязчив, но труднее всего реализовать (бегуны - это волосатые твари, одна из заявленных целей @Rule заключалась в том, чтобы устранить большую часть необходимости их создавать).
Другой - сделать предположение, что утверждение в тесте проверяет некоторые настройки конфигурации, которые будут истинными, если этот тест будет запущен. На самом деле это потребует инъекции прямо в тест, что, скорее всего, нарушит условия сделки в чем-либо, удаленно обозначенном как «отдельный проект».
Сейчас это вам не поможет, но TestNG поддерживает такого рода способности.
Я могу придумать возможность достичь желаемого с указанными ограничениями, используя модификацию байт-кода. Вы можете сохранить список классов и методов, которые следует игнорировать, в отдельном файле и исправлять байт-код тестовых классов при их загрузке, чтобы полностью удалить эти методы.
Если я не ошибаюсь, JUnit использует отражение для поиска теста методы для выполнения. Затем операция переименования метода позволит вам удалить эти методы до того, как JUnit найдет их. Или метод можно изменить так, чтобы он возвращался немедленно, без выполнения каких-либо операций.
Библиотека, такая как BCEL , может использоваться для изменения классов при загрузке.
Если вы хотите запустить только часть тестов, это звучит как будто у этого класса больше одной ответственности, и его нужно реорганизовать. В качестве альтернативы тестовый класс может быть разбит на части, чтобы в исходном проекте были все тесты, кроме одного или нескольких классов (я предполагаю, что некоторые из тестов действительно являются интеграционными тестами и касаются базы данных или сети), и вы можете исключить класс ( es) вы не хотели.
Если вы не можете сделать ничего из этого, ваш вариант переопределения, вероятно, лучший. Возьмите процесс всякий раз, когда вам нужно игнорировать некоторые методы, вы расширяете этот класс и добавляете его в свой список исключений Ant. Таким образом, вы можете исключить то, что не можете пройти, и по-прежнему будете использовать все новые тесты (методы, которые вы не переопределяли, и новые тестовые классы) без изменения вашей сборки.
ваш вариант переопределения, вероятно, лучший. Возьмите процесс всякий раз, когда вам нужно игнорировать некоторые методы, вы расширяете этот класс и добавляете его в свой список исключений Ant. Таким образом, вы можете исключить то, что не можете пройти, и по-прежнему будете использовать все новые тесты (методы, которые вы не переопределяли, и новые тестовые классы) без изменения вашей сборки. ваш вариант переопределения, вероятно, лучший. Возьмите процесс всякий раз, когда вам нужно игнорировать некоторые методы, вы расширяете этот класс и добавляете его в свой список исключений Ant. Таким образом, вы можете исключить то, что не можете пройти, и по-прежнему будете использовать все новые тесты (методы, которые вы не переопределяли, и новые тестовые классы) без изменения вашей сборки.Хорошо, это довольно тяжелое решение, но не бросайте в меня вещи, если это звучит нелепо.
Ядром Junit4 является класс org.junit.runner.Runner и его различные подклассы, в первую очередь org.junit.runners.Suite . Эти бегуны определяют тесты для данного тестового класса, используя такие вещи, как @Test и @Ignore.
Довольно легко создавать собственные реализации бегуна, и обычно вы подключаете их, используя аннотацию @RunWith в ваших тестовых классах, но, очевидно, это не вариант для вас.
Однако теоретически вы могли бы написать свою собственную задачу Ant, возможно, основанную на стандартной задаче Ant Junit, которая берет ваш пользовательский модуль запуска тестов и использует его напрямую, передавая ему каждый тестовый класс по очереди. Ваша реализация runner может использовать внешний файл конфигурации, в котором указывается, какие методы тестирования следует игнорировать.
Это будет довольно много работы, и вам придется потратить время на копание в доисторической кодовой базе Ant Junit, чтобы узнать, как оно работает. Однако затраченное время может того стоить.
Жаль, что задача Junit Ant не предоставляет механизма для определения Test Runner, который был бы идеальным.
Если нежелательные тесты находятся в определенных классах / пакетах, вы можете использовать набор файлов exclude в Ant, чтобы исключить их во время импорта.