Я могу автоматически выполнить тестовые сценарии JUnit однажды со всем включенным входом и однажды со всем отключенным входом?
Для справки, Фонд Свифта CharacterSet может использоваться в пределах разделения:
альтернатива 1
extension String {
var lines: [String] {
return split { String([110]).rangeOfCharacter(from: .newlines) != nil }.map(String.init)
}
}
альтернатива 2
extension String {
var lines: [String] {
return split { CharacterSet.newlines.contains([111].unicodeScalars.first!) }.map(String.init)
}
}
5 ответов
Я решил эту проблему, реализовав базовый класс, который тестовые классы должны расширять, если требуется такая функциональность.
Статья Написание параметризованного теста JUnit содержала решение.
См. LoggingTestBase для базового класса ведения журнала и LoggingTestBaseExampleTest для простого примера его использования.
Каждый содержащийся метод тестирования выполняется трижды:
1 . Он выполняется, как обычно, с использованием ведения журнала, как определено в logback-test.xml. Предполагается, что это поможет при написании / отладке тестов.
2. Он выполняется со всеми включенными журналами и записывается в файл. Этот файл удаляется после проверки.
3. Он выполняется с отключенным протоколированием.
Да, LoggingTestBase требует документации;)
Вы пробовали просто поддерживать два отдельных файла конфигурации журнала? Каждый из них будет регистрироваться на разных уровнях от корневого регистратора.
Все журналы отключены :
...
<root>
<priority value="OFF"/>
<appender-ref ref="LOCAL_CONSOLE"/>
</root>
...
Все журналы включены :
...
<root>
<priority value="ALL"/>
<appender-ref ref="LOCAL_CONSOLE"/>
</root>
...
Выполнение будет указывать различные конфигурации в пути к классам через системный параметр:
-Dlog4j.configuration=path/to/logging-off.xml
-Dlog4j.configuration=path/to/logging-on.xml
Я бы порекомендовал переключиться с JUnit на TestNG. TestNG имеет множество дополнительных функций по сравнению с JUnit. Это позволяет вам запускать тесты несколько раз с разной конфигурацией, и я думаю, это то, что вам нужно
eqbridges предложение просто запустить тесты дважды с разными контекстами ведения журнала кажется самым простым. Вам не нужно запоминать логику в каждом благословенном тесте, чтобы получить одно большое преимущество. Во-вторых, вы можете очень легко увидеть, какой уровень ведения журнала виноват.
При этом есть несколько стратегий, если вам просто нужно сделать это за один тестовый прогон.
Для 3.8 я бы все поместил в suites и создайте два набора, по одному для каждого уровня ведения журнала, которые задают уровень ведения журнала перед запуском тестов. Функционально это то же самое, что дважды запустить весь набор тестов с разными параметрами командной строки, за исключением того, что вы получаете его за один запуск.
В JUnit 4.x на ум приходит пара дополнительных параметров:
Один из них - это кастомный бегун. Хотя я могу Я не думаю обо всем, что вам нужно сделать, чтобы заставить эту работу работать, но бегун, который фактически запускает тест дважды и аннотирует тест с помощью @RunW с вашим индивидуальным бегуном, может работать.
Другой - параметризованные тесты. Хотя на самом деле вам придется настроить каждый тест для приема параметров (для этого требуется конструктор, который принимает аргументы), а затем установить уровень журнала в соответствии с параметром.
РЕДАКТИРОВАТЬ: В ответ на ваш запрос о практических рекомендациях по параметризованные тесты, здесь - это javadoc для бегуна, который поможет вам начать работу, а здесь - более практическое руководство.
If you feel you have too much logging if you turn everything on, perhaps you could try to cut down the amount of logging. Its not very useful if it too much for the computer to procude never mind a human to read.