Интересная реакция. Вам дали список недочетов, некоторые из которых будут блокировать повтор действий из этой статьи, а в ответ — 🤣. Прошлый материал был более профессиональным.
Может, надо более точечно было написать, что вот тут: Appium настроен, теперь можно переходить к настройке конфигурации. Создаем конфиг для Appium и конфиг для Selenoid: неплохо было бы указать, какой именно файл создается и где.
А тут "image": ["appium", "--config", "/Users/mobilefarm.am/selenoid/config/appium/iphonex.json"] поделиться секретным содержимым файла iphonex.json .
Для людей же пишете, а не для KPI по статьям на отдел.
С версиями аппиума тоже есть нюанс. Видимо, вы не в курсе, но раньше при установке беты второго аппиума для IP из России сыпались интересные сообщения в консоль. А может там еще и какие-то скрипты дополнительно исполнялись. И потому было бы неплохо иметь какие-то гарантии, что никаких сюрпризов не будет при установке и после (вы же в альфе делаете какие-то проверки, а не тупо ставите всё подряд?).
И если вам нужно , нет, спасибо, давайте без предположений. Я просто хотел почитать качественную статью.
В блоке с конфигами для аппиума и селеноида нет пояснения, где создавать файлы и как называть. В конфиге селеноида есть пути до файлов, но снова нет пояснения, что то за файлы и что в них должно быть и почему такие пути.
Нет объяснения параметров запуска селеноида.
Опечатка в команде для аппиум-доктора.
И нет варианта с запуском симулятора.
Пока что по этой статье шаг за шагом выполнить вряд ли получится задуманное.
Ну вот так точно не надо писать — не надо делать из айтишников каких-то особенных. Они ничем не отличаются от других таких же рядовых сотрудников компании. А так вы только раскалываете, полностью перекладывая финансовый успех на одно направление.
Раз статья для новичков, то выделю то, что их хорошему не научит.
"message_text" и "chat_id" — в джаве принят другой формат именования переменных.
Смущает ".split(" ");" — а если пользователь ввел два и более пробелов случайно? А если клиент телеграма перестанет убирать пробелы до и после текста сообщения, которые тоже случайно были добавлены? А обработка текста со спецсимволами? А если вес на одной строке, а рост на другой? Так что надо тримить, а после из двух и более пробелов делать одинарный. А еще может потом захочется сделать другой разделитель, точка с запятой или еще что-то. А еще проверка на валидность роста, например, что выше 250 быть не может. Кейсов накидать можно много, но хотело бы видеть хотя бы намеки на проверки, хотя бы комментариями. Понятно, что это пет проджект и не более, но привычка подумать о том, как реальный человек будет пользоваться — всегда пригодится. "Все остальные запросы должны блокироваться" — все же это слишком искусственное требование.
Не очень понятно, в чем смысл проверки на наличие пробела ("// если сообщение с текстом содержит пробел"). Она вообще не нужна. Вы же в любом случае делаете массив строк через split и если длина не 2, то отправляете ошибку.
Название переменной "weightAntHeight" тоже не отражает сути массива и может путать.
И неплохо было бы добавить обработку, что если сообщение "/start", то высылать инструкцию. для тех, кто впервые открыл его.
Читая статью, я не знаю, что такое "WriteUser" и "ImtCount". Для этого надо лезть на гитхаб и изучать уже там. Но вот в самой статье это мешает и не несет никакой смысловой нагрузки. Лучше расписать про базу в следующих статьях, материала-то можно много сделать.
Если без этих мелочей, то статья хорошая, пишите еще.
Смотрите, что я увидел. Вы для автотестов предлагаете писать pipeline, при этом в вашем примере я не вижу ничего такого, чего нельзя было бы сделать через freestyle job. Если я перепишу ваш пайплайн на freestyle job, он разве станет "несложным"?
Как инженер, я хотел бы видеть какую-то аргументацию посильнее, чем Если же нужно, что-то более кастомное, то тут нам на помощь приходит Pipeline. Пример: отправка уведомления на почту. В freestyle нет возможности указать тело сообщения, в Pipeline - можно. Как минимум по той причине, что для тех же уведомлений на почту есть плагин Email Extension (https://plugins.jenkins.io/email-ext/), который позволяет настраивать что угодно и сейчас ставится чуть ли не по дефолту. Аналогично и с плагином для слака — полная кастомизация (справедливости ради добавлю, что через пайплайн можно настроить еще лучше, но для автоматизации это излишне — нам же по сути нужен статус прогона и ссылка на него).
Аргументы с официального сайта, конечно, хороши, но это не ваш опыт. Сравните хотя бы картину пайплайна по ссылке с тем, что описано у вас. И далее по списку преимуществ — часто ли у вас перезапускается контроллер Jenkins, часто ли вам нужно писать реально сложные пайплайны с ветвлениями и зацикливаниями, часто ли вы используете настраиваемые расширения для своего DSL? Почему-то кажется, что вообще нет. Что по всем этим пунктам ответ будет отрицательный. И в таком случае получается, что у такого подхода для автотестов нет преимущества. Для полноценного процесса развертки + тестирования + деплоя — да. Но статья не про это. Ну и следом был бы вопрос — а чем этот подход лучше написания скрипта на груви?
Не поймите неправильно, статья отличная, но для автоматизации тестирования я только один аргумент увидел — хранение в vcs. Но и на это можно возразить, что если джобы настолько сложные, что их нужно где-то хранить, то скорее всего что-то делаете не так.
Интересная реакция. Вам дали список недочетов, некоторые из которых будут блокировать повтор действий из этой статьи, а в ответ — 🤣. Прошлый материал был более профессиональным.
Может, надо более точечно было написать, что вот тут:
Appium настроен, теперь можно переходить к настройке конфигурации. Создаем конфиг для Appium и конфиг для Selenoid:неплохо было бы указать, какой именно файл создается и где.
А тут
"image": ["appium", "--config", "/Users/mobilefarm.am/selenoid/config/appium/iphonex.json"]поделиться секретным содержимым файла
iphonex.json.Для людей же пишете, а не для KPI по статьям на отдел.
С версиями аппиума тоже есть нюанс. Видимо, вы не в курсе, но раньше при установке беты второго аппиума для IP из России сыпались интересные сообщения в консоль. А может там еще и какие-то скрипты дополнительно исполнялись. И потому было бы неплохо иметь какие-то гарантии, что никаких сюрпризов не будет при установке и после (вы же в альфе делаете какие-то проверки, а не тупо ставите всё подряд?).
И если вам нужно, нет, спасибо, давайте без предположений. Я просто хотел почитать качественную статью.Не указана версия аппиума.
В блоке с конфигами для аппиума и селеноида нет пояснения, где создавать файлы и как называть. В конфиге селеноида есть пути до файлов, но снова нет пояснения, что то за файлы и что в них должно быть и почему такие пути.
Нет объяснения параметров запуска селеноида.
Опечатка в команде для аппиум-доктора.
И нет варианта с запуском симулятора.
Пока что по этой статье шаг за шагом выполнить вряд ли получится задуманное.
Ну вот так точно не надо писать — не надо делать из айтишников каких-то особенных. Они ничем не отличаются от других таких же рядовых сотрудников компании. А так вы только раскалываете, полностью перекладывая финансовый успех на одно направление.
Раз статья для новичков, то выделю то, что их хорошему не научит.
"message_text" и "chat_id" — в джаве принят другой формат именования переменных.
Смущает ".split(" ");" — а если пользователь ввел два и более пробелов случайно? А если клиент телеграма перестанет убирать пробелы до и после текста сообщения, которые тоже случайно были добавлены? А обработка текста со спецсимволами? А если вес на одной строке, а рост на другой? Так что надо тримить, а после из двух и более пробелов делать одинарный. А еще может потом захочется сделать другой разделитель, точка с запятой или еще что-то. А еще проверка на валидность роста, например, что выше 250 быть не может. Кейсов накидать можно много, но хотело бы видеть хотя бы намеки на проверки, хотя бы комментариями. Понятно, что это пет проджект и не более, но привычка подумать о том, как реальный человек будет пользоваться — всегда пригодится. "Все остальные запросы должны блокироваться" — все же это слишком искусственное требование.
Не очень понятно, в чем смысл проверки на наличие пробела ("// если сообщение с текстом содержит пробел"). Она вообще не нужна. Вы же в любом случае делаете массив строк через split и если длина не 2, то отправляете ошибку.
Название переменной "weightAntHeight" тоже не отражает сути массива и может путать.
И неплохо было бы добавить обработку, что если сообщение "/start", то высылать инструкцию. для тех, кто впервые открыл его.
Читая статью, я не знаю, что такое "WriteUser" и "ImtCount". Для этого надо лезть на гитхаб и изучать уже там. Но вот в самой статье это мешает и не несет никакой смысловой нагрузки. Лучше расписать про базу в следующих статьях, материала-то можно много сделать.
Если без этих мелочей, то статья хорошая, пишите еще.
Смотрите, что я увидел.
Вы для автотестов предлагаете писать pipeline, при этом в вашем примере я не вижу ничего такого, чего нельзя было бы сделать через freestyle job. Если я перепишу ваш пайплайн на freestyle job, он разве станет "несложным"?
Как инженер, я хотел бы видеть какую-то аргументацию посильнее, чем
Если же нужно, что-то более кастомное, то тут нам на помощь приходит Pipeline. Пример: отправка уведомления на почту. В freestyle нет возможности указать тело сообщения, в Pipeline - можно. Как минимум по той причине, что для тех же уведомлений на почту есть плагин Email Extension (https://plugins.jenkins.io/email-ext/), который позволяет настраивать что угодно и сейчас ставится чуть ли не по дефолту. Аналогично и с плагином для слака — полная кастомизация (справедливости ради добавлю, что через пайплайн можно настроить еще лучше, но для автоматизации это излишне — нам же по сути нужен статус прогона и ссылка на него).Аргументы с официального сайта, конечно, хороши, но это не ваш опыт. Сравните хотя бы картину пайплайна по ссылке с тем, что описано у вас. И далее по списку преимуществ — часто ли у вас перезапускается контроллер Jenkins, часто ли вам нужно писать реально сложные пайплайны с ветвлениями и зацикливаниями, часто ли вы используете настраиваемые расширения для своего DSL? Почему-то кажется, что вообще нет. Что по всем этим пунктам ответ будет отрицательный. И в таком случае получается, что у такого подхода для автотестов нет преимущества. Для полноценного процесса развертки + тестирования + деплоя — да. Но статья не про это. Ну и следом был бы вопрос — а чем этот подход лучше написания скрипта на груви?
Не поймите неправильно, статья отличная, но для автоматизации тестирования я только один аргумент увидел — хранение в vcs. Но и на это можно возразить, что если джобы настолько сложные, что их нужно где-то хранить, то скорее всего что-то делаете не так.
А в чем преимущество такого подхода перед, например, freestyle job? Кроме того, что этот jenkinsfile можно хранить в vcs.