Хороший обзор, скину коллегам почитать. Из мелочей: вроде frozenset через z, и вот этот код можно было бы детальнее прокомментировать:
def func(first, second, *, kwonly):
Насчёт “GDB с плагином к Python” — это может быть чересчур, если есть Visual Studio 2017, которая поддерживает mixed Python+C отладку (это есть ещё с VS 2015 вроде, но там это сильно торомозило и роняло студию, насколько я помню).
Отличная статья! По примеру 4: есть аналогичная фишка в Python (разница между time.time() и timeit.default_timer() — такая же, и мы это видели отнюдь не в UI тестах, мы железо тестируем), ещё там же заметил опечатку в коде: в первом куске long en (должно быть long end).
Рейтинг тупо по звёздам на гитхабе. Ниже ещё есть по вопросам на StackOverflow, но там я про Appium забыл. В следующем месяце добавлю, он там будет лидером. :)
Так получилось, что pywinauto я использую с 2010 года и начал поддерживать его в опен сорсе с лета 2015-го. Поддержку UIA мы выпустили в ноябре 2016-го, а WinAppDriver появился весной 2016-го. Узнал я про WinAppDriver в июне 2017-го. В этом году гонка продолжается. Мы уже год работаем над "record-replay" фичей (планируем релизить осенью, думали, что будем первыми в опен сорсе с подобным), а Microsoft взял да и выпустил свой UI Recorder в июне этого года. Правда, я его пробовал и пока не смог получить ничего вменяемого.
А десктоп мало чем тестируется, и не всякий. Из юзабельных — топ-12 из рейтинга, который я обновляю раз в месяц. На каждой оси — свои технологии доступа к текстовым свойствам. На Windows большинство покрывается технологией MS UI Automation API: она сложна, поэтому есть более простые в освоении библиотеки (это pywinauto, TestStack.White, MS WinAppDriver, FlaUI и Winium.Desktop). На Линуксе это AT-SPI, но там реально простых библиотек пока нет, есть зубодробительные. На макоси есть встроенный AppleScript и pyatom — очень даже годный, хоть и Python2.7 только и в установке не очень прост. Я со своими студентами пытаюсь все эти технологии собрать в pywinauto в максимально простом виде, тут ещё 2-3 года работы, учитывая, что это хобби (на основной работе я сейчас вообще не GUI занимаюсь). Ещё есть распознавалки эталонных картинок типа Sikuli, pyautogui, lackey. Они менее надёжны и подкушивают CPU, но зато универсальней не придумаешь.
Привет от декстопников. Для десктопного UI точно так же полезно детальнее указывать, где именно находится кнопка, какой у неё class_name, title и так далее. Какие-то вещи вроде ControlID или обычного индекса лучше не использовать. В общем, некоторые отличия разве что в списке стабильных и не очень стабильных пропертей/локаторов.
Что касается вменяемых ошибок, то это вообще к любому коду относится, не только к тестам.
Ну, и под инфраструктуру Selenium есть майкрософтовский WinAppDriver. Они нас внезапно опередили с релизом UI Recorder'а — они пока единственные с такой фичей в опен сорсе (правда, я ещё не пробовал, но полагаю, что он тоже на текстовых свойствах, иначе смысла нет).
Из годных топ-12 вот отсюда: https://github.com/pywinauto/pywinauto/wiki/UI-Automation-tools-ratings Из них pyautogui, sikuli и lackey работают фактически только с картинками, autopy — вообще только с голой мышкой и клавиатурой. Остальные в той или иной степени с текстовыми свойствами элементов (как правило, на одной оси). Из быстрорастущих тулов под C# можно отметить молодой проект FlaUI, автор которого занимался поддержкой TestStack.White, но плюнул и решил сделать с нуля.
SWAPY сейчас не поддерживается. Он совместим только со старой версией pywinauto 0.5.4, где был единственный backend="win32" и все методы в стиле CamelCase. Вроде бы на третьем питоне он работал. В любом случае, pywinauto 0.5.4 работает на третьем питоне, как и более новые.
Вообще, у меня студенты набросали инспектор объектов: https://github.com/pywinauto/py_inspect
Всего на 150 строк кода. Правда, полуручного генератора скриптов там нет, зато можно переключать бэкенды. В будущем мы хотим вернуться к нему и полноценно встроить в экосистему, если раньше кто-нибудь не поможет.
Сейчас главные приоритеты — это генератор скриптов в стиле "record-replay" и поддержка Линукса.
Отличное начинание, молодцы! Но сайт у вас не работает. :( И ещё вопрос: насколько строгий у вас пропускной режим? Ну, и все остальные вопросы, которые на сайте, наверно, отражены.
Ещё странно, что не рассмотрен Sikuli, который как раз под Jython заточен и весьма известен. Или я что-то пропустил спросонья. Под чистый CPython есть его аналог Lackey, который, впрочем, кривоват и плохо уживается с другими библиотеками. Не уверен, что Sikuli может юзать GPU, да и кэш скорее всего тоже пришлось бы писать.
Сами студенты занимаются именно разработкой, а не продвижением. Если студент толковый, то примерно за первые полгода он уже может научиться писать достаточно чистый и качественный код с юнит тестами (по крайней мере, в рамках проекта), дальше только помогаешь технические проблемы решать и задаешь направления. Как-нибудь напишу об этом статью, наверно.
Хороший способ и студентов прокачать, и проекты продвинуть. Сам активно привлекаю студентов для проекта по автоматизации десктопного GUI. Впрочем, для Embedded систем навряд ли что-то такое осуществимо в ближайшее время.
Грустная история. Мне как раз интересно было, как ребята Яндекс.Браузер тестируют…
История с велосипедом, оставшимся внутри компании, не нова. Почему-то мало кто опен сорсит код в этой нише.
Уже куплена неделю назад. :) И коллегам нравится. На Хабре как раз месяц назад статья была с отрывком из неё, так и нашёл.
def func(first, second, *, kwonly):
Отличная статья! По примеру 4: есть аналогичная фишка в Python (разница между time.time() и timeit.default_timer() — такая же, и мы это видели отнюдь не в UI тестах, мы железо тестируем), ещё там же заметил опечатку в коде: в первом куске long en (должно быть long end).
Единственно, надо понимать, что Appium изначально был для мобилок и его рейтинг будет прихватывать более широкую целевую аудиторию.
Рейтинг тупо по звёздам на гитхабе. Ниже ещё есть по вопросам на StackOverflow, но там я про Appium забыл. В следующем месяце добавлю, он там будет лидером. :)
Так получилось, что pywinauto я использую с 2010 года и начал поддерживать его в опен сорсе с лета 2015-го. Поддержку UIA мы выпустили в ноябре 2016-го, а WinAppDriver появился весной 2016-го. Узнал я про WinAppDriver в июне 2017-го. В этом году гонка продолжается. Мы уже год работаем над "record-replay" фичей (планируем релизить осенью, думали, что будем первыми в опен сорсе с подобным), а Microsoft взял да и выпустил свой UI Recorder в июне этого года. Правда, я его пробовал и пока не смог получить ничего вменяемого.
Вообще, умеет. Как раз майкрософтовский WinAppDriver совместим с Appium, и там есть на 14-м месте appium-for-mac. :)
А десктоп мало чем тестируется, и не всякий. Из юзабельных — топ-12 из рейтинга, который я обновляю раз в месяц. На каждой оси — свои технологии доступа к текстовым свойствам. На Windows большинство покрывается технологией MS UI Automation API: она сложна, поэтому есть более простые в освоении библиотеки (это pywinauto, TestStack.White, MS WinAppDriver, FlaUI и Winium.Desktop). На Линуксе это AT-SPI, но там реально простых библиотек пока нет, есть зубодробительные. На макоси есть встроенный AppleScript и pyatom — очень даже годный, хоть и Python2.7 только и в установке не очень прост. Я со своими студентами пытаюсь все эти технологии собрать в pywinauto в максимально простом виде, тут ещё 2-3 года работы, учитывая, что это хобби (на основной работе я сейчас вообще не GUI занимаюсь). Ещё есть распознавалки эталонных картинок типа Sikuli, pyautogui, lackey. Они менее надёжны и подкушивают CPU, но зато универсальней не придумаешь.
Привет от декстопников. Для десктопного UI точно так же полезно детальнее указывать, где именно находится кнопка, какой у неё class_name, title и так далее. Какие-то вещи вроде ControlID или обычного индекса лучше не использовать. В общем, некоторые отличия разве что в списке стабильных и не очень стабильных пропертей/локаторов.
Что касается вменяемых ошибок, то это вообще к любому коду относится, не только к тестам.
Ну, и под инфраструктуру Selenium есть майкрософтовский WinAppDriver. Они нас внезапно опередили с релизом UI Recorder'а — они пока единственные с такой фичей в опен сорсе (правда, я ещё не пробовал, но полагаю, что он тоже на текстовых свойствах, иначе смысла нет).
Из годных топ-12 вот отсюда: https://github.com/pywinauto/pywinauto/wiki/UI-Automation-tools-ratings Из них pyautogui, sikuli и lackey работают фактически только с картинками, autopy — вообще только с голой мышкой и клавиатурой. Остальные в той или иной степени с текстовыми свойствами элементов (как правило, на одной оси). Из быстрорастущих тулов под C# можно отметить молодой проект FlaUI, автор которого занимался поддержкой TestStack.White, но плюнул и решил сделать с нуля.
SWAPY сейчас не поддерживается. Он совместим только со старой версией pywinauto 0.5.4, где был единственный backend="win32" и все методы в стиле CamelCase. Вроде бы на третьем питоне он работал. В любом случае, pywinauto 0.5.4 работает на третьем питоне, как и более новые.
Вообще, у меня студенты набросали инспектор объектов: https://github.com/pywinauto/py_inspect
Всего на 150 строк кода. Правда, полуручного генератора скриптов там нет, зато можно переключать бэкенды. В будущем мы хотим вернуться к нему и полноценно встроить в экосистему, если раньше кто-нибудь не поможет.
Сейчас главные приоритеты — это генератор скриптов в стиле "record-replay" и поддержка Линукса.
На здоровье! Осталось только machine learning прикрутить. :) Акциями же торгуют боты, почему мебелью нельзя?
Сами студенты занимаются именно разработкой, а не продвижением. Если студент толковый, то примерно за первые полгода он уже может научиться писать достаточно чистый и качественный код с юнит тестами (по крайней мере, в рамках проекта), дальше только помогаешь технические проблемы решать и задаешь направления. Как-нибудь напишу об этом статью, наверно.
Грустная история. Мне как раз интересно было, как ребята Яндекс.Браузер тестируют…
История с велосипедом, оставшимся внутри компании, не нова. Почему-то мало кто опен сорсит код в этой нише.