где пруфы, Билли? :) Ну а вообще каждый видит то что он хочет видеть. Автор видит все в темных тонах, а я такого не замечаю, регулярно пишут НР с хорошими вилками.
А есть наработки как контролировать, что изменения были согласно новой фиче? А еще интересно, что делать если мы имеем несколько веток невмерженных в мастер и в каждой свои отличия?
а почему не пойти дальше не создавать в ci пользователей на этапе деплоя сервиса. еще можно держать копию бд которая на начало дня содержит 1000 созданных юзеров, которые расходуются на тесты, а ночью накатывается новая база. ну и еще я не верю что для 1000 тестов надо создавать пользователя, почти наверняка хватит меньше десятка на все кейсы.
Соглашусь с предыдущими ораторами. В целом плохо представляю ситуацию, когда команда сама не знает из-за чего у нее проблемы, чтобы еще зачем-то собирать метрики, которые в разных спринтах будут показывать диаметрально противоположные данные.
Особо не нравилось то что блютус старый, музыку слушаешь когда часто есть помехи и радиус покрытия меньше, ну и хром само собой (любой браузер) просто мог не тянуть некоторые сайты, например google keep.
Завидую вам, ребята, меня производительность 2011-2012 что-то прямо бесит при том, что у меня ничего особого не запускается, до 2014 грустные железки на мой вкус.
1,5 года, а у вас?
где пруфы, Билли? :) Ну а вообще каждый видит то что он хочет видеть. Автор видит все в темных тонах, а я такого не замечаю, регулярно пишут НР с хорошими вилками.
Конечно, можно сделать проверку параметризированной, я скорее про то, что стоит упомянуть об этом в статье с таким заголовком.
А есть наработки как контролировать, что изменения были согласно новой фиче? А еще интересно, что делать если мы имеем несколько веток невмерженных в мастер и в каждой свои отличия?
я бы добавил недопустимые типы данных еще, проверки на тип запроса, как-то не заметил проверки статусов и т.д. Это точно полное покрытие?
Редко использую такие проверки в тестах, они хоть что-то ловят, если учитывать, что оно почти наверняка покрыто в юнитах?
а почему не пойти дальше не создавать в ci пользователей на этапе деплоя сервиса. еще можно держать копию бд которая на начало дня содержит 1000 созданных юзеров, которые расходуются на тесты, а ночью накатывается новая база. ну и еще я не верю что для 1000 тестов надо создавать пользователя, почти наверняка хватит меньше десятка на все кейсы.
по-моему, в данном случае гораздо быстрее было написать самому, но если сделано ради прикола, то почему бы и нет.
Соглашусь с предыдущими ораторами. В целом плохо представляю ситуацию, когда команда сама не знает из-за чего у нее проблемы, чтобы еще зачем-то собирать метрики, которые в разных спринтах будут показывать диаметрально противоположные данные.
Playwright пробовали?
Отправить в Анализатор - крайне неудачная формулировка. Не очень понятно, что тут ключевое Отправить или Анализатор.
Лучше пройти тестовое и получить отказ, чем через месяц снова искать работу.
Прохожу, не вижу проблем.
Из моей практики не было ни разу, чтобы отказались от тестового. Зато вместо тысяч собеседований я провёл всего сотни.
Особо не нравилось то что блютус старый, музыку слушаешь когда часто есть помехи и радиус покрытия меньше, ну и хром само собой (любой браузер) просто мог не тянуть некоторые сайты, например google keep.