А если лень делать QR-код, как вариант свой корпоративный ТГ-бот в который можно отписать, Кто, какое устройство, зачем и когда и прикапывать в банальной SQLite или Redis и одним запросом через него же узнать где устройство. А так тут огромное поле для оптимизации подобного процесса
Из статьи заметил, что НТ проводилось на прод поде который вывели для этих самых тестов? Если подобные тесты будут больше проводиться в будущем, то мне кажется вам стоит заказать отдельные тестовые стенды приближенные к продуктивным (6 подов бэка и фронт как я прочитал) и уже на них проводить нагрузочное.
Статистика только одного пода это конечно хорошо, но имхо стоит также и все поды нагрузить дабы увидеть как совместно они эту нагрузку делят
Ну по моему опыту написанию автотестов я вам точно скажу что такой подход bad practice) Лучше делать явные ожидания, и читабельность выше и производительность хорошая
Мне кажется стоит упомянуть немало важный показатель в автотестах, так это их атомарность. Он то как раз и будет экономить стоимость автотестов (за счет сокращения больших E2E тестов), они также будут стабильны за счет независимости.
Если говорить про steps, то я отчасти согласен, что подобную модель может быть трудоемко поддерживать, он если один steps используют несколько тестов, то и по факту не сильно проигрываем в поддержке относительно трудоемкости, но подобные ситуации индивидуальны и не берусь говорить что так надо и делать
Пока что у нас есть только 1: “local.yaml”, необходимо создать второй: “local_tests.yaml”. В нем оставим все те же настройки, кроме одной - timeout. Изменим ее значение с 4s на 10h
Уместно ли такое утверждение для автотестов? Если подобное работает локально и не расписанию (в CI/CD по шедулеру), то я еще понимаю такое растягивание таймаутов, но при использовании подобного в прогонах не аффектим ли мы общую статистику выполнения автотестов?
А если говорить про кейсы то деление на 0 наверное то что хотелось бы увидеть (Не знаю умеет ли go в генерацию 0.0 функцией generateRandomFloat)
Создание ферм виртуальных устройств на IOS не то что требует больших затрат, я бы сказал космические. Была подобная задача, поставить 5 симулятор IOS для автотестов, и если с Android настройка у нас заняла 2-3 дня, то с IOS мы промучались более 3 недель, т.к подстроить капризную mac os под автотесты было довольно трудно и шаг влево, шаг вправо и заново настраивать и тратить время и ресурсы
А если лень делать QR-код, как вариант свой корпоративный ТГ-бот в который можно отписать, Кто, какое устройство, зачем и когда и прикапывать в банальной SQLite или Redis и одним запросом через него же узнать где устройство. А так тут огромное поле для оптимизации подобного процесса
Из статьи заметил, что НТ проводилось на прод поде который вывели для этих самых тестов?
Если подобные тесты будут больше проводиться в будущем, то мне кажется вам стоит заказать отдельные тестовые стенды приближенные к продуктивным (6 подов бэка и фронт как я прочитал) и уже на них проводить нагрузочное.
Статистика только одного пода это конечно хорошо, но имхо стоит также и все поды нагрузить дабы увидеть как совместно они эту нагрузку делят
Ну по моему опыту написанию автотестов я вам точно скажу что такой подход bad practice) Лучше делать явные ожидания, и читабельность выше и производительность хорошая
Мне кажется стоит упомянуть немало важный показатель в автотестах, так это их атомарность. Он то как раз и будет экономить стоимость автотестов (за счет сокращения больших E2E тестов), они также будут стабильны за счет независимости.
Если говорить про steps, то я отчасти согласен, что подобную модель может быть трудоемко поддерживать, он если один steps используют несколько тестов, то и по факту не сильно проигрываем в поддержке относительно трудоемкости, но подобные ситуации индивидуальны и не берусь говорить что так надо и делать
Уместно ли такое утверждение для автотестов?
Если подобное работает локально и не расписанию (в CI/CD по шедулеру), то я еще понимаю такое растягивание таймаутов, но при использовании подобного в прогонах не аффектим ли мы общую статистику выполнения автотестов?
А если говорить про кейсы то деление на 0 наверное то что хотелось бы увидеть (Не знаю умеет ли go в генерацию 0.0 функцией
generateRandomFloat)Создание ферм виртуальных устройств на IOS не то что требует больших затрат, я бы сказал космические. Была подобная задача, поставить 5 симулятор IOS для автотестов, и если с Android настройка у нас заняла 2-3 дня, то с IOS мы промучались более 3 недель, т.к подстроить капризную mac os под автотесты было довольно трудно и шаг влево, шаг вправо и заново настраивать и тратить время и ресурсы