Daniel Haimov@saratoga8
Software Automation Engineer
Информация
- В рейтинге
- Не участвует
- Зарегистрирован
- Активность
Специализация
Десктоп разработчик, Инженер по автоматизации тестирования
Старший
Python
Linux
ООП
Git
Docker
JavaScript
TypeScript
Software Automation Engineer
"
В другой публикации он добавил: “Программирование всегда было мучением. Необходимой болью почти для каждого, кто хотел заставить компьютер делать что-то полезное. И я рад, что с этим покончено”.
"
Просто избавился от того, что не любил
Какое же тут достижение или прогресс?
может путешественников из будущего нет, потому что и человечества нет в будущем
возможно люди исчезнут, не успев создать машину времени
Интересно, а что будут делать миллиард безработных в Китае, которых быстрыми темпами заменили роботами? Мне кажется, чувство тревоги должно быть в поднебесной как раз
Спасибо за интересную статью!
Подскажите как беречь модели от пыли? Я так понимаю, парусник тряпочкой не повытираешь
не рассчитывайте на поиск локаторов по тексту - UI/UX очень часто и легко меняет текст элементов. Например:
определили локатор "//*[text()='Очистить историю']"
через неделю, дизайнеры UI/UX решили, что текст должен быть 'очистить историю'
и тест упал из-за одной буквы
спасибо за статью!
самый устойчивый локатор - data-testid
его добавляют разработчики для тестовых целей. он может быть добавлен по просьбе разработчиков автоматического тестирования
в остальных случаях, нет никаких устойчивых локаторов. фронт-энд разработчики изменять код и не спросят авто-тестировщиков. тесты попадали - проблема тестировщиков, а не фронт-энда
исходя из собственного опыта, могу сказать - все решает взаимодействие разработчик-тестировщик. если этого нет - головная боль, нервы, обиды
Спасибо за интересную статью!
Несколько вопросов:
- Насколько ваши генерируемые тесты информативны и помогают найти источник проблемы?
- Насколько ваши генерируемые тесты независимы друг от друга, например каждый тест работает в динамически созданном аккаунте на время работы теста
- Соответствуют ли генерируемые тесты формату ААА?
Спасибо за интересную статью
Советую использовать для проектирования проектов методологию BDD и Impact Mapping
они облегчают понимание целей проекта
Спасибо за статью
Вспомнил Милтона из Office Space
Из всех рассмотренных в статье фреймворков только 2 связаны с ИИ (Selenium, на сколько я знаю, не связан)
Пожалуйста добавляйте линки на приведённые вами фреймворки
Спасибо за статью
Советую для большей информативности фейлов, добавлять в ассерты error messages
Например:
assert len(input_requests) == 1, "Invalid number input requests"И использовать более расширенные ассерт библиотеки, вроде PyHamcrest
Про мнения философов и гуру ИИ о том какие опасности нас ждут с ИИ, советую послушать подкасты Лекса Фридмана с Юваль Ноа Харари и Романом Ямпольским.
Я слушал без перевода, возможно где-то есть перевод или субтитры:
https://youtu.be/Mde2q7GFCrw - с Харари
https://youtu.be/NNr6gPelJ3E - с Ямпольским
- Софочка, почему моя бутылка коньяка на половину пустая!?
- Фима, ты таки не оптимист! Она же все еще на половину полная
Я имел в виду, уходит со сцены популярности. Электронщики и микро электронщики сегодня по прежнему важны, без них невозможно программирование и индустрия it. Но сегодня электронщики, это архитекторы и дизайнеры электроники и микро электроники, а не фрики с паяльниками как во время расцвета электроники.
В статье описано куда дует ветер, туда где будет что-то большее, чем просто кодинг и игры с фреймворками и библиотеками
Спасибо за интересную статью!
Мне кажется, уходит эпоха популярности программирования, которая сменила популярную электронику, сменившую популярную механику
Программисты по прежнему будут нужны, но не будут уже "модными айтишниками"
Важно уметь принять наступающие изменения и использовать их
Спасибо за статью
Заголовок статьи не говорит на основе чего сравниваются языки. Судя по содержанию, для сравнения используются только мат. вычисления. Возникает вопрос - почему именно они?
Спасибо за интересную статью.
Мне кажется, что самые сложные задачи и принятия решений надо делать до обеда. А позже заниматься менее сложными делами. Важно отключаться на короткое время от работы, болтая с сотрудниками о жизни рядом с кофе машиной или где еще
(просто из моего опыта)
Мне кажется, что юнит тесты должны присутствовать всегда (поэтому, в пирамиде тестов их так много), они как знак качества добавленного кода
Дальше, разработчик уже сам решает какие остальные виды тестирования имплементировать. Потому что, здесь уже все зависит от доступного времени и людских ресурсов. И не стоит стремиться к 100% покрытия тестами. Здесь понимание важнее статистики
В случае веб разработки, очень сложно создавать юнит тесты. Из моего опыта могу сказать, что почти все веб проекты которые я видел, были без юнит тестов
В этом примере я тоже не делал юнит тестов из-за простоты самого проекта. Но очень хотел бы услышать мнение веб разработчиков, как бы они добавили юнит тесты в данный проект