Почему процессы, созданные через терминал прибиваются через время? Запускал в скрине минимальный сервер на Python aiohttp, работает минут 20. Нагрузки, конечно никакой.
Если это ожидаемое поведение, есть способы «договориться»? Сервисом оформить или по-другому…

На самом деле там было много Start* методов, пожалуй слишком много: start()/Start()/start_()/Start_()/__start(). Еще Марк пометил статические Start*/Connect* как deprecated. Фактически, мы просто закончили переезд и убрали лишнее. В статических методах все-равно был вызов методов инстанса, решили уйти от таких неявных вызовов.

Я правильно понял, что TextTest является своеобразным GUI прокси — самостоятельно отрисовывает тестовое окно и записывает все действия?
А есть ли возможность тестировать UI уже готового exe?

Ясно, у меня тоже все напрямую идет.

Но радист внутри меня тихо шипит и презирает меня за это :)

Интересно как себя чувствует контроллер когда вы «по необходимости оснащаю свой рюкзак солнечными элементами». Ведь меняются характеристики (V, A). Важно чтобы солнечные элементы работали в режиме максимальной мощности, тогда из них можно выжать заявленное КПД.

Если интересно, я на подобном солнечном элементе сделал электронные солнечные настольные часы. video.yandex.ua/users/moden-py/view/1/#
Без всяких контроллеров, параметры элемента в условиях обычного освещения комнаты как раз подошли.
Все работает до сих пор…

Еще есть Boa Constructor — Python IDE — wxPython GUI Builder.
Проект довольно популярен, хотя последнее обновление от 2007-07-05.
Сам пользовал его для освоения wxPython на Windows и Ubuntu.
Все просто и удобно (для старта). Сейчас предпочитаю доделывать форму ручками.

Карма или рейтинг позволили — переместил в Тестирование.

Э, нет. Там был список опций с фильтром. Когда опцию выделяешь, появляется кнопка или чекбокс в зависимости от типа опции. Так вот, если выделить опцию, затем применить фильтр(что бы выбранная опция исчезла), то относящиеся к опции кнопка/чекбокс остаются на UI. Если попытаться нажать/изменить — краш.

Нет, краши. Один связан с динамически появляющимися элементами. Если просто, то при попытке открыть опции элемента, которого уже нет на окне.
Второй — это краш сервиса, который стартовал/останавливал тяжелую операцию по команде из GUI. Тут просто повезло.
Вспомнил. Еще были зависания UI — что то с синхронизацией сервис-ui.
А лики систематически приходили с добавлением новой функциональности.

К сожалению не все. Навороченные контролы (html layout, и т.д.) pywinauto просто не распознает.
И это самая большая печалька.

Пардон за коменты — я еще не совсем освоился. Исходя из личного опыта только два серьезных кейса было найдено таким способом. Но оно того стоило… А для поиска ликов — самое оно.
На счет предложения. Это поломает концепцию случайного кликанья. Я вот подумываю о том, что бы добавить некоторые цепочки для зависимых элементов. Например, после ввода а edit нажать энтер. Но что бы оставалась случайность, следует наделить второе действие весом (вероятнее всего будет нажат энтер, но может и просто окно закрыть). Но это нужно хорошенько обдумать.

это правда.

> Выход от таких тестов к сожалению очень не большой. Но подход крайне интересный.