Извлекаемый контент не должен быть защищен авторским правом
А как узнать, что это так? Декларированы ли стандарты размещения предупреждении об авторских правах?
И еще вопрос — а является ли парсинг сайтов с незаконно выложенной информацией нарушением закона? Например, я уверен, что не все сайты, где можно читать книги онлайн, имеют права на публикацию этих самых книг. Теоретически, если я написал парсер на сбор этих книг в PDF, я преступник?
Несколько вопросов по поводу показателя покрытия UI тестов:
1) Насколько вы ему доверяете? Откуда берется понимание, что действительно все кейзы так или иначе описаны в тестах?
2) Не думали ли вы про приоритезацию кейзов? Чисто интуитивно кажется, что todo на тест покупки должен «бить» по покрытию больше, чем todo теста на клик какой-нибудь мало популярной ссылки в футере.
3) Этот показатель как-то влияет на ваши процессы? Если он падает, о чем это вам говорит? Есть ли у него какой-то минимум, после которого весь отдел автоматизации дружно выбрасывается в окно начинает работать по ночам?
Хорошая киллер-фича. Использовать ее я, конечно, не буду. :)
А вообще мне статья понравилась. Я узнал что-то новое — про кнопку «e» в vim. И я улыбнулся, читая ее. Конечно, я не перестану пользоваться теперь IDE.
Я спорить не хотел, просто думал поугорать над статьей. По докату показалось, что тут бугогашенька будет. Извините, но забавно не вышло.
Вроде в начале почти улыбнуло, но к концу второго пункта на лицо вернулся привычный покерфейс. :(
На серьезность статья тоже явно не тянет. Все это обычное недовольное ёрзание пятой точки по стулу в надежде заново напустить актуальности устаревшим темам. Языки смешивались и будут смешиваться. К месту употребленное слово (читай — термин) на вес золота, а если собеседник дурак, так и не важно, на каком языке он глаголит.
Спасибо за статью. Я с удовольствием посмеялся над пунктом три, и мне понравился последний пункт про запуск тестов не только локально.
Но в целом от такой статьи хотелось бы побольше примеров «из жизни» и, возможно, «вредных» примеров и антипаттернов для наглядности. Некоторые пункты показались довольно банальными.
Конечно, «тавтологичность» зависит от неправильного и неразумного использования моков. Меня смутило, судя по всему как и автора предыдущего комментария, напутствие использовать моки как можно чаще. Было бы правильно упомянуть в этом пункте и про подводные камни, коих не мало. Все таки статья посвящена правильному написанию unit-тестов.
Принципиально другим решением было бы какое-о изменение процесса, которое вело бы к более стабильным тестам или что-то вроде того.
Одно другому не мешает. Со стороны тестов тоже были сделаны изменения. Я об этом писал в той части, где рассказывал о подготовительных работах, о TeamCity, и о сломанных и нестабильных тестах.
А что делать мануальным тестировщикам, которые из-за увеличения загрузки автоматизацией, не будут успевать делать свои задачи?
Вы же понимаете, что автоматизаторы не бегают среди прикованных цепями ручников, заставляя во что бы то не стало править тесты и наливать себе кофе?
Если у тестировщика задача сверх срочная и большая — хотя я упоминал в статье, что такое бывает не часто и давал ссылку на статью, где мы рассказываем, как планируем сроки — само собой, он может обратиться за помощью ко мне или другому автоматизатору и мы поможем ему поправить тесты. Главное, что мы сделает это до того, к задача окажется в релизе. Это и есть то принципиально новое, о чем Вы спрашиваете, как мне кажется.
Если же в задаче надо поправить один-два локатора, согласитесь, это не сильно замедлит тестирование задачи и не отнимет много времени у тестировщика.
Когда только начинали писать selenium-тесты, скачали себе последнюю на тот момент версию Facebook Webdriver Framework (https://github.com/facebook/php-webdriver). Сами тесты писали, используя Phpunit Framework (https://github.com/sebastianbergmann/phpunit).
Однако у нас появлялись какие-то свои решения и хотелки, которые мы самостоятельно вносили в FB Framework. Сейчас он довольно сильно переписан и имеет мало общего с текущей версией.
У нас есть внутренние проекты, которые мы покрываем новой версией FB Framework и собираем все через Composer, стараясь не влезать в код библиотек. Не могу сказать, что это принесло какие-то плюшки против собственного фреймворка. Просто эти проекты поменьше и тестов там тоже меньше.
Codeception мы не пробовали внедрять. В тесты для боевого проекта это будет сделать неоправданно сложно. Возможно мы опробуем его на каком-то из внутренних проектов и тогда я напишу свое мнение. :)
Я здесь не достаточно корректно написал, согласен. Имеется в виду, что как только релиз оказывается на стейджинге, у нас есть где-то 4 часа на его проверку, прежде чем он окажется на продакшене. В какой-то момент мы оказались в ситуации, когда все эти 4 часа уходили на следующее.
Мы проверяли каждый тест, если он падал из-за бага, искали тикет, который этот функционал сломал, чтобы либо запатчить, либо откатить, в зависимости от серьезности проблемы.
Если же тест падал из-за изменений, мы либо чинили его, если это было быстро и у нас еще оставалось время, любо откладывали его починку и проверяли функционал руками. Само собой, работать в такой суматохе было довольно сложно, к тому же мы рисковали иногда в спешке ошибочно решить, что тест падает, «это не страшно, поправлю потом».
Сейчас тестирование релиза происходит куда спокойнее.
Почему поднятием тестов занимается не программист? Зачем лишнее звено — автотестер?
Именно запуском тестов у нас вообще занимаются скрипты или CI, в зависимости от окружения. Все автоматизированно.
Что касается починкой тестов. У нас в компании написанием функциональных тестов занимается отдел тестирования. Это наш инструмент для более тщательной и быстрой проверки функционала. Следовательно и починкой занимаемся тоже мы. Во-первых, мы уже знаем как эти тесты устроены, так как сами их разработали, во-вторых, когда тест падает, именно нам нужна информация о том, почему он упал. Может быть это не тест надо править, а тикет переоткрывать.
Именно это решение вы и реализовали, разве нет? Вы попытались сделать из «ручных тестеров» «автоматизаторов», но почему-то не путем повышения квалификации, а путем снижения порога входа и упрощением системы тестов (что само по себе стоит дорого)
В чем-то Вы правы, мы действительно научили ребят из ручного тестирования работе с тестами. Но те задачи, которые они решают, это еще не все задачи, которые в целом существуют в автоматизации.
Они, по сути, работают уже с готовым фреймворком и готовым окружением, в рамках которых пишут новые тесты или правят старые. Но поддержание этой архитектуры, создание базового кода, настойка автозапусков, обновление selenium, браузеров и прочего тоже занимает время. Этим у нас уже по большей части занимаются автоматизаторы.
До этого не так? Как вы убивались об версионирование кода приложения и кода тестов?
До этого мы запускали тесты с ветки Master и вносили изменений тоже в Master. В целом такой подход работал. Но иногда были сложности, да. Например, мы вносили правки к задаче, которая еще была в релизе, а потом ее откатывали. Сейчас, когда мы запускаем тесты с ветки релиза, все стало удобнее и лучше.
Вы не считаете порочным деление на «автоматизаторов»" и «ручных тестеров»? Автоматизация всего лишь инструмент. Ваши автоматизаторы тестировать умеют?
Лично я такое деление не считаю порочным. У нас это скорее не вопрос способности, а определение зоны ответственности. Я прихожу каждый день на работу, пью кофе и сажусь работать с автотестами. Кто-то приходит, кушает булочку и садится тестировать задачи. Каждый занимается своим делом. :)
1) Да, мы ведем учет тестов. Само собой, речь идет не о покрытий строк кода, как для unit-тестов. Ведь даже простое открытие страницы чаще всего затрагивает много классов и методов, хотя мы еще ничего не проверили. Для функциональных тестов мы считаем, какое количество фич мы покрыли автотестами, из общего их количества. У нас есть внутренний документ, где мы ведём подобную статистику.
Когда появляется новый функционал на сайте, мы дописываем его в этот документ, и покрытие падает. Когда пишем тесты — покрытие снова оказывается на прежнем уровне. Так мы развиваем покрытие «в ширину».
Помимо этого, как я уже писал в одном из комментариев, если тестировщик находит баг, который автотестами был пропущен, мы ставим тикет на автоматизацию. Это помогает «углубиться» в тестирование фичи, покрывая ее особенно уязвимые кейзы.
2) Существует некоторое конечное число направлений, в которых мы развиваем автоматизацию у нас в компании. Биллинг и интерфейсы, Desktop Web, Mobile Web, iOS и Android приложения, тестирование API и так далее. За каждый компонент отвечает один человек. Он знает, какие тесты есть, и через его код-ревью как правило проходит весь-весь-весь новый код, связанный с его зоной ответственности. Таким образом он следит за повторениями.
Помимо этого у нас есть внутренние документы, которые я описал выше. Они тоже помогает в решении такой задачи.
Можно было и так написать. Но я боялся, что подобной формулировкой не донесу свою основную мысль. Автотесты — это инструмент, который в умелых руках упрощает и ускоряет работу тестировщика. Умение с ним работать — само по себе профит. Не считая того, что это дополнительный навык работы с кодом в целом, что довольно важно в IT-индустрии.
Тут, как и с любым инструментом, надо начинать знакомиться с простых вещей. Можно показать, как запускать тесты. Если это сделано неудобно, стоит сначала оптимизировать процесс. Чем проще запустить тест, тем чаще его будут запускать.
Далее важно сделать удобный вывод репорта об ошибке. У нас он пишет, какой user был авторизован, делает скриншот и HTML-слепок, пишет строку для перезапуска теста в консоли и так далее.
Сами тексты ошибок, которые формируются, если элемент не найден или какой-то assert не сработал, стоит писать подробно. Так, чтобы глядя на скриншот было понятно, в чем проблема.
Только когда тесты готовы к тому, чтобы ими можно был легко пользоваться, стоит привлекать тестировщиков или девелоперов к их использованию. Тут важно не спугнуть. :)
Что касается работе с кодом, само собой все приходит с опытом. Волне нормально, если допускаются стилистические или даже логические ошибки. Для этого есть код-ревью, где более опытный коллега может подсказать верное решение.
Да, конечно, иногда бывает так, что тест проверяет фичу не в полном объеме и пропускает что-то. Обычно такое отлавливается как раз ручными тестировщиками, которые находят баг руками и видят, что тест его пропустил.
Если это не долго, тестировщик может сам добавить нужную проверку. Если же это займет существенное время, ставит тикет.
Более того, у нас устроено так, что для любого тикета с пометкой баг автоматически ставится QA-тикет на дописание нужного теста. Это очень удобно и положительно влияет на покрытие.
Спасибо за Ваш интерес к нашему коду. К сожалению, я не увидел в Вашем комментарии четко сформулированного вопроса, только поток сознания. :)
Что касается оффтопа, то может Вам стоит написать статью о том, как Вы организовываете свой код тестов и какой профит с этого имеете? С удовольствием почитаю. Только соберите мысли в порядок и пишите побольше наглядных примеров. Удачи!
Локаторы должны быть привязаны к классам и тегам так, чтобы было ясно назначение элемента. За локатор вида //span[1]/div[3]/form[1]/input[3] расстрел вне очереди.
Там довольно много рекомендаций, которые работаю для нашего проекта.
По поводу локаторов. Например, новые локаторы мы стараемся писать на css, однако если правится локатор, который уже написан на xpath, переводить его на css не стоит — высока вероятность, что этот локатор складывается с другим.
Еще пример. Бывает, что в xpath-локаторе у одного тега описывается сразу два класса:
Дело в том, что классы элементам довольно часто добавляются динамически через JS, а значит асинхронно. И порядок, в котором классы будут добавлены, может меняться. В итоге элемент не будет находиться, а тест будет падать через раз.
Или как правильно работать с SVG, используя xpath-локаторы.
В целом там довольно много примеров, все не перечислить. Мы туда добавляем все знания, которые кажутся нам важными или из-за которых мы сталкивались с какими-то сложностями.
Да, забыл про второй вопрос.
У нас код в тест-классах всегда начинается с методов-тестов. Если в классе есть какие-то вспомогательные функции, они всегда лежат ниже по коду. Само собой, приведенный Вами пример имеет право на существование, но в нашей архитектуре крайне маловероятен.
А как узнать, что это так? Декларированы ли стандарты размещения предупреждении об авторских правах?
И еще вопрос — а является ли парсинг сайтов с незаконно выложенной информацией нарушением закона? Например, я уверен, что не все сайты, где можно читать книги онлайн, имеют права на публикацию этих самых книг. Теоретически, если я написал парсер на сбор этих книг в PDF, я преступник?
Несколько вопросов по поводу показателя покрытия UI тестов:
1) Насколько вы ему доверяете? Откуда берется понимание, что действительно все кейзы так или иначе описаны в тестах?
2) Не думали ли вы про приоритезацию кейзов? Чисто интуитивно кажется, что todo на тест покупки должен «бить» по покрытию больше, чем todo теста на клик какой-нибудь мало популярной ссылки в футере.
3) Этот показатель как-то влияет на ваши процессы? Если он падает, о чем это вам говорит? Есть ли у него какой-то минимум, после которого весь отдел автоматизации дружно
выбрасывается в окноначинает работать по ночам?А вообще мне статья понравилась. Я узнал что-то новое — про кнопку «e» в vim. И я улыбнулся, читая ее. Конечно, я не перестану пользоваться теперь IDE.
Я спорить не хотел, просто думал поугорать над статьей. По докату показалось, что тут бугогашенька будет. Извините, но забавно не вышло.
Вроде в начале почти улыбнуло, но к концу второго пункта на лицо вернулся привычный покерфейс. :(
На серьезность статья тоже явно не тянет. Все это обычное недовольное ёрзание пятой точки по стулу в надежде заново напустить актуальности устаревшим темам. Языки смешивались и будут смешиваться. К месту употребленное слово (читай — термин) на вес золота, а если собеседник дурак, так и не важно, на каком языке он глаголит.
Но в целом от такой статьи хотелось бы побольше примеров «из жизни» и, возможно, «вредных» примеров и антипаттернов для наглядности. Некоторые пункты показались довольно банальными.
Одно другому не мешает. Со стороны тестов тоже были сделаны изменения. Я об этом писал в той части, где рассказывал о подготовительных работах, о TeamCity, и о сломанных и нестабильных тестах.
Вы же понимаете, что автоматизаторы не бегают среди прикованных цепями ручников, заставляя во что бы то не стало править тесты и наливать себе кофе?
Если у тестировщика задача сверх срочная и большая — хотя я упоминал в статье, что такое бывает не часто и давал ссылку на статью, где мы рассказываем, как планируем сроки — само собой, он может обратиться за помощью ко мне или другому автоматизатору и мы поможем ему поправить тесты. Главное, что мы сделает это до того, к задача окажется в релизе. Это и есть то принципиально новое, о чем Вы спрашиваете, как мне кажется.
Если же в задаче надо поправить один-два локатора, согласитесь, это не сильно замедлит тестирование задачи и не отнимет много времени у тестировщика.
То, о чем Вы говорите, там есть.
Однако у нас появлялись какие-то свои решения и хотелки, которые мы самостоятельно вносили в FB Framework. Сейчас он довольно сильно переписан и имеет мало общего с текущей версией.
У нас есть внутренние проекты, которые мы покрываем новой версией FB Framework и собираем все через Composer, стараясь не влезать в код библиотек. Не могу сказать, что это принесло какие-то плюшки против собственного фреймворка. Просто эти проекты поменьше и тестов там тоже меньше.
Codeception мы не пробовали внедрять. В тесты для боевого проекта это будет сделать неоправданно сложно. Возможно мы опробуем его на каком-то из внутренних проектов и тогда я напишу свое мнение. :)
Я здесь не достаточно корректно написал, согласен. Имеется в виду, что как только релиз оказывается на стейджинге, у нас есть где-то 4 часа на его проверку, прежде чем он окажется на продакшене. В какой-то момент мы оказались в ситуации, когда все эти 4 часа уходили на следующее.
Мы проверяли каждый тест, если он падал из-за бага, искали тикет, который этот функционал сломал, чтобы либо запатчить, либо откатить, в зависимости от серьезности проблемы.
Если же тест падал из-за изменений, мы либо чинили его, если это было быстро и у нас еще оставалось время, любо откладывали его починку и проверяли функционал руками. Само собой, работать в такой суматохе было довольно сложно, к тому же мы рисковали иногда в спешке ошибочно решить, что тест падает, «это не страшно, поправлю потом».
Сейчас тестирование релиза происходит куда спокойнее.
Именно запуском тестов у нас вообще занимаются скрипты или CI, в зависимости от окружения. Все автоматизированно.
Что касается починкой тестов. У нас в компании написанием функциональных тестов занимается отдел тестирования. Это наш инструмент для более тщательной и быстрой проверки функционала. Следовательно и починкой занимаемся тоже мы. Во-первых, мы уже знаем как эти тесты устроены, так как сами их разработали, во-вторых, когда тест падает, именно нам нужна информация о том, почему он упал. Может быть это не тест надо править, а тикет переоткрывать.
В чем-то Вы правы, мы действительно научили ребят из ручного тестирования работе с тестами. Но те задачи, которые они решают, это еще не все задачи, которые в целом существуют в автоматизации.
Они, по сути, работают уже с готовым фреймворком и готовым окружением, в рамках которых пишут новые тесты или правят старые. Но поддержание этой архитектуры, создание базового кода, настойка автозапусков, обновление selenium, браузеров и прочего тоже занимает время. Этим у нас уже по большей части занимаются автоматизаторы.
До этого мы запускали тесты с ветки Master и вносили изменений тоже в Master. В целом такой подход работал. Но иногда были сложности, да. Например, мы вносили правки к задаче, которая еще была в релизе, а потом ее откатывали. Сейчас, когда мы запускаем тесты с ветки релиза, все стало удобнее и лучше.
Лично я такое деление не считаю порочным. У нас это скорее не вопрос способности, а определение зоны ответственности. Я прихожу каждый день на работу, пью кофе и сажусь работать с автотестами. Кто-то приходит, кушает булочку и садится тестировать задачи. Каждый занимается своим делом. :)
Спасибо за Ваши вопросы и Ваш отзыв.
1) Да, мы ведем учет тестов. Само собой, речь идет не о покрытий строк кода, как для unit-тестов. Ведь даже простое открытие страницы чаще всего затрагивает много классов и методов, хотя мы еще ничего не проверили. Для функциональных тестов мы считаем, какое количество фич мы покрыли автотестами, из общего их количества. У нас есть внутренний документ, где мы ведём подобную статистику.
Когда появляется новый функционал на сайте, мы дописываем его в этот документ, и покрытие падает. Когда пишем тесты — покрытие снова оказывается на прежнем уровне. Так мы развиваем покрытие «в ширину».
Помимо этого, как я уже писал в одном из комментариев, если тестировщик находит баг, который автотестами был пропущен, мы ставим тикет на автоматизацию. Это помогает «углубиться» в тестирование фичи, покрывая ее особенно уязвимые кейзы.
2) Существует некоторое конечное число направлений, в которых мы развиваем автоматизацию у нас в компании. Биллинг и интерфейсы, Desktop Web, Mobile Web, iOS и Android приложения, тестирование API и так далее. За каждый компонент отвечает один человек. Он знает, какие тесты есть, и через его код-ревью как правило проходит весь-весь-весь новый код, связанный с его зоной ответственности. Таким образом он следит за повторениями.
Помимо этого у нас есть внутренние документы, которые я описал выше. Они тоже помогает в решении такой задачи.
Далее важно сделать удобный вывод репорта об ошибке. У нас он пишет, какой user был авторизован, делает скриншот и HTML-слепок, пишет строку для перезапуска теста в консоли и так далее.
Сами тексты ошибок, которые формируются, если элемент не найден или какой-то assert не сработал, стоит писать подробно. Так, чтобы глядя на скриншот было понятно, в чем проблема.
Только когда тесты готовы к тому, чтобы ими можно был легко пользоваться, стоит привлекать тестировщиков или девелоперов к их использованию. Тут важно не спугнуть. :)
Что касается работе с кодом, само собой все приходит с опытом. Волне нормально, если допускаются стилистические или даже логические ошибки. Для этого есть код-ревью, где более опытный коллега может подсказать верное решение.
Главное начать! А опыт придет.
Да, конечно, иногда бывает так, что тест проверяет фичу не в полном объеме и пропускает что-то. Обычно такое отлавливается как раз ручными тестировщиками, которые находят баг руками и видят, что тест его пропустил.
Если это не долго, тестировщик может сам добавить нужную проверку. Если же это займет существенное время, ставит тикет.
Более того, у нас устроено так, что для любого тикета с пометкой баг автоматически ставится QA-тикет на дописание нужного теста. Это очень удобно и положительно влияет на покрытие.
Что касается оффтопа, то может Вам стоит написать статью о том, как Вы организовываете свой код тестов и какой профит с этого имеете? С удовольствием почитаю. Только соберите мысли в порядок и пишите побольше наглядных примеров. Удачи!
Такие дела :)
По поводу локаторов. Например, новые локаторы мы стараемся писать на css, однако если правится локатор, который уже написан на xpath, переводить его на css не стоит — высока вероятность, что этот локатор складывается с другим.
Еще пример. Бывает, что в xpath-локаторе у одного тега описывается сразу два класса:
//div/a[contains(@class,"added active")]То лучше эти два класса разделять вот так:
//div/a[contains(@class,"added")][contains(@class,"active")]Дело в том, что классы элементам довольно часто добавляются динамически через JS, а значит асинхронно. И порядок, в котором классы будут добавлены, может меняться. В итоге элемент не будет находиться, а тест будет падать через раз.
Или как правильно работать с SVG, используя xpath-локаторы.
В целом там довольно много примеров, все не перечислить. Мы туда добавляем все знания, которые кажутся нам важными или из-за которых мы сталкивались с какими-то сложностями.
У нас код в тест-классах всегда начинается с методов-тестов. Если в классе есть какие-то вспомогательные функции, они всегда лежат ниже по коду. Само собой, приведенный Вами пример имеет право на существование, но в нашей архитектуре крайне маловероятен.