testomat.io управление авто тестамиВ тестах используются перменные из файла пропертис. После небольших апдейтов была переименована одна из переменных и добавлено несколько новых в файл пропертис
При запуске локально - всё ок,тесты проходят
Но при прогоне на дженкинс получаю вот такую ошибку java.lang.IllegalArgumentException: Keys to send should be a not null CharSequence когда доходит до использования одной из переменных,которые я упомянул выше.
Если бы у меня не совпадали названия переменных в пропертис и в самом коде,то такая ошибка должна была возникнуть и локально.А тут именно при прогоне на дженкинс.
Помоните понять в чем причина
Такое ощущение, что переменные непроинициализовываются => получаете NPE.
Проверьте еще раз в дженкинсе, чтение пропрети файла идет первым ?
Выведите в лог значения всех переменных.
- точно из файла читаете? может некорректно прописали путь к ресурсу?
- не могло быть проблемы с кодировкой? И или с переносом строки (там у Linux / Windows разные они)
- хороший совет от Артура - вывести в лог, всё что есть, тогда будет понятно есть ли там такое свойство или реально null
Можно вывести, всё что вычитывается из properties файла и вывести в консоль или же лог:
Properties prop = new Properties();
InputStream iStream = new ClassPathResource("test.properties").getInputStream();
prop.load(iStream);
Enumeration<?> enumeration = prop.propertyNames();
while (enumeration.hasMoreElements()){
String key = enumeration.nextElement().toString();
System.out.println(key + " = " + prop.getProperty(key));
}
или вот так:
try (InputStream input = new FileInputStream("src/test/resources/test.properties")) {
Properties prop = new Properties();
prop.load(input);
Enumeration<?> enumeration = prop.propertyNames();
while (enumeration.hasMoreElements()){
String key = enumeration.nextElement().toString();
System.out.println(key + " = " + prop.getProperty(key));
}
} catch (IOException ex) {
ex.printStackTrace();
}
Или как там сейчас модно читать этот файл? Через аннотации в спрингбуттесте?
И, конечно же, классика жанра: буквы кириллического или украинского алфавита вместо английского в имени ключей тех свойств, которые пытаетесь вычитать или внутри этого файла. Особенно нужно следить за всякими “е”, “о”, “а”, “р”, “i” и т.п.
Я в какой-то момент зарёкся делать ctrl + c / ctrl + v из спецификаций, т.к. там никогда не знаешь где ждать подставы. Самый трешовый вариант у меня был с кириллицей внутри слова (как будто специально туда внесли её) в название колонки. Причем оно в таком виде долго-долго жило на локальных докер базах, но накрылось медным тазом при раскатке на реальный контур, где выставили завесу от вот таких вот имён.
Та должно быть первым.
Там в кейсе до этой переменной берутся значения для логина из пропертис.
В таком бы случае тест падал сразу на логине,а так падает уже когда доходит до действий с этой переменной
1.Точно путь прописан правильно,потому что до этого читало и всё было ок. И в пропертис есть другие переменные,которые удачно используются. А проблема именно вот на изменненной переменной и новой переменной
2.Наверное сразу откидывается этот вариант,учитывая первый пункт
3.Нужно попробовать, но на дженкинсе настроено делать скриншот при ошибки.И явно видно что просто не подставляется значение переменной из пропертис
По классике жанра - был бы реальный вариант. Но если бы были буквы на англ алфавита,то я ж так понимаю что и локально из-за этого падал тест,а так он работает.
@Zhenya_Shahov по итогу что-то было сделано? В лог что-то выводили? Проблема решилась или так и осталось?
Если проблема не в вашем коде, значит проблема в окружении, которое отличается на вашей локальной машине и на CI Jenkins’а. Надо сравнивать в чём ваши окружения различаются. Сходу могу сказать, что под подозрением могут быть JDK, maven/gradle и т.д.
Сам недавно ловил “подозрительную” ошибку из-за неправильного докер-образа на CI, точнее неправильную JDK внутри него, в которой не хватало нужных сертификатов и из-за этого при сборке выкидывалась ошибка, якобы об отсутствии доступа к другому ресурсу. Также я сам сталкивался с бажными версиями maven, собственно самой JDK, gradle и т.д. Или к примеру с бажной версией библиотеки JDBC от Oracle для Java8, внутри которой были классы скомпилированные под JDK10, из-за этого на чистой JDK8 это не работало и сборка падала. А вот на JDK 11 всё работало успешною. Собственно, если вы точно убедились, что проблема не в вашем коде, то нужно копать в сторону различий окружения. В том числе и например версии операционных систем. Тривиально пути к файлам в Win / Linux долгое время создавали проблемы из-за различий / и \, тоже самое и про переносы строк CR, LF, CRLF и т.д.
@Mihail_Bratuhin проверял выводом в логи переменных с пропертис на дженкинсе.В итоге ,все нужные переменные и их значения выводит
@Zhenya_Shahov т.е. проперти прочитался, все ключи в нём с значение присутсвтуют, но в метод они почему-то не попали?
да,а уже при выполнении метода,где эта переменная из пропертис используется, выдаёт эту ошибку
Возможно, уже есть заранее такая же переменная(окружения) объявленная с таким же именем где-то и она дублируется ?
Потому не то значение подставляется ?
проверял этот момент, но название переменной уникально и больше нигде не повторяется
Ну, тут есть как минимум несколько вариантов:
- кто-то или что-то стирает или заменяет значение в этой переменной.
- передача в метод происходит раньше, чем нужное значение попадает в саму пропертю. Обычно такое происходит со статик полями / методами, но может ещё из-за параллельного исполнения и выполнения в отдельных потоках или т.п.
- может не работать передача параметра в метод, например, если реализовано через аннотацию и обработчик почему-то не сработал как надо или читаете не из той проперти, например, где-то System.properties, а где-то System.env, или вообще другая Properties. Надо убедиться, что для передачи в метод используется именно нужная пропертя с лежащим в ней значением.
- ну, и в конце уже можно думать о фазах Солнца и Луны, багах в конкретных библиотеках / фрейворках / ОС / железе и т.д.(ну и эти проблемы исключать не стоит, особенно зная как отлично сочетаются версии вэбдрайвера и браузеров).
З.Ы. пробелемы с паралельным исполеннием и ситуацией гонок вообще бывает очень неочевидными и более того, часто режим debug и / или вывод в лог может менять ситуацию (тормозить один из потоков) и в результате не давать воспроизвести ситуацию.
Ну, и конечно для отладки можно попробовать “вхардкодить” значение и посмотреть как оно себя поведёт на CI, если не из проперти будет браться. Плюс хорошо бы точно убедиться под какой версией java собирается проект, а то индусы в интернете по этой проблеме очень советуют что-то пошаманить с версией JDK и проекта.
добавил вывод значения переменной уже в самом методе - и там уже null
Но, самое интересное - поменял название переменной в пропертис на старое(которое было раньше) и всё заработало
спасибо за помощь и подсказки. Методом подстановки разных наименований переменных и их значений в пропертис понял что на каком-то этапе просто смотрит вообще не в те пропертис…И как оказалось:
В методе загрузки и выбора пропертис(куай/прод и т.д.) было указано два варианта выбора пропертис: в первом варианте был явно прописан путь к пропертис,а во втором,как-бы так сказать, файл с пропертис определялся автоматом. И это всё было обернуто в try-catch.Типа когда 1 вариант не срабатывал,то использовался 2 вариант
Явный путь был написан не правильно,как буд-то он указан для удаленной машины
И вот,локально при запуске по 1 варианту по указанному пути не находило пропертис и срабатывал 2 вариант,и всё было отлично
А когда уже на дженкинс запускалось,то получается по 1 первому пути лежат файлы-пропертис,но они старые,и поэтому падало с такой ошибкой