Об асинхронности и модальности в GUI тестах

Об асинхронности и модальности в GUI тестах

О тестах GUI я писал тут - http://18delphi.blogspot.ru/2013/11/gui.html ну и "в последующих сериях".

Сегодня я размышлял над одной хорошей заметкой моего товарища по цеху - Романа Янковского.

О Awaitable-значениях (http://roman.yankovsky.me/?p=1100).

И неожиданно понял - что ещё я хочу сказать о GUI-тестировании.

Есть два момента с которыми рано или поздно сталкиваются GUI-тестировщики. Когда система входит в такое состояние, когда она блокирует управление и крутит какой-то "внутренний цикл".

А именно:

1. Например показ контекстного меню или что-то подобное.
2. Показ модального диалога и ожидание ввода пользователя.

И это далеко не самая простая проблема.

Ведь код теста - "замораживается" и система "ждёт ввода от пользователя" и тесты на это повлиять никак уже не могут.

Им банально - не отдаётся управление. И они не могут продолжать свою работу.

А ведь - они автоматические и никакой пользователь им не поможет.

Что же делать?

Не перестаю восхищаться библиотекой STL

Не перестаю восхищаться библиотекой STL.

Сегодня правил одну уж очень заковыристую ошибку со сложными структурами данных, так в итоге она крайне элегантно разрешилась при помощи рекурсивных алгоритмов. Я даже сначла сам не понял - "что именно я сделал".

Код "реальной" скриптовой машины

Код "реальной" скриптовой машины.

Вот тут - http://18delphi.blogspot.ru/2013/11/gui-back-to-basics_22.html я писал про устройство скриптовой машины.

А вот тут - https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/ScriptEngine/ я решил выложить код "реальной" скриптовой машины.

Он - НЕ скомпилируется. Но думаю, что ОСОБЕННО пытливым читателям - будет интересен.

Ссылка. "Декорирование элементов перечисления"

Ссылка. "Декорирование элементов перечисления"

Прочитал тут ссылку:

http://blogs.embarcadero.com/nikolay/2013/11/25/scopedenumeration/

Прикольно. В плане "синтаксического сахара".

Непонятно только - зачем понадобился helper. Почему просто определение констант не подошло?

Да и ничего "изящного" - я не вижу. Я РЕАЛЬНО не понимаю ЧЕМ - TMyType.Three СИЛЬНО лучше, чем mtThree.

РЕАЛЬНО не понимаю. Может быть мне дураку кто-нибудь объяснит?

Нет! ВОЗМОЖНОСТЬ - это - ХОРОШО, но это не значит, что надо "бросаться пользоваться этой возможностью".

А ещё можно всё то же самое с модели сгенерировать. Один раз поправив шаблоны генерации. 

Заметки о тестировании №2

Предыдущая серия "потока сознания была тут" - http://programmingmindstream.blogspot.ru/2013/11/blog-post.html

Продолжу.

Пока не забыл.

Опять же о "линейности" и "читаемости человеком".

Пусть нам в каком-то тесте надо поработать с состоянием системы с пользовательской настройкой отличной от умолчания.

Первое что приходит на ум это примерно следующее:

var
 SomeSettingValue : Value;
...
 SomeSettingValue := System.GetValue('SomeSetting');
 DoOurWork;
 System.SetValue('SomeSetting', SomeSettingValue );

- ну что сказать? А если тест упадёт? Всё? Система окажется в нестабильном состоянии? Ну "решение на поверхности" такое:

var
 SomeSettingValue : Value;
...
 SomeSettingValue := System.GetValue('SomeSetting');
 try
  System.SetValue('SomeSetting', SomeNewSettingValue);
  DoOurWork;
 finally
  System.SetValue('SomeSetting', SomeSettingValue );
 end;

- оно конечно лучше.

Но по-моему это то самый случай, когда "за деревьями скрывается лес".

Все эти try..finally явно не повышают читабельность.

Для человека, который должен мочь "читать тест" и "воспринимать его как тест-кейс".

"Хорошее" решение, как мне кажется выглядит примерно так:

 TemporaryChangedSystemStateFor('SomeSettingValue', SomeNewSettingValue, DoOurWork);

Ну или "по-русски":

 "Для шрифта системы в {(20px)}" "Построить предварительный просмотр и сравнить с эталоном" 

Опять же - разница вроде бы невелика. Тонкая грань. Вкусовщина.

Но! С одной стороны мы обеспечиваем стабильность автоматических тестов, а с другой стороны мы не перегружаем человека читающего это лишней информацией.

Если человек читает первоначальный вариант и выполняет тест, то он вроде бы как обязан - вернуть все настройки в исходное состояние.

А если он руками дальше не будет ничего тестировать? Зачем ему это?

А если будет, то там есть - "подсказка".

Но именно - подсказка, а не побуждение к действию.

Ну вот как-то так мне кажется.

Опять же - ни на чём - не настаиваю.

Заметки о тестировании

Ещё раз хочу повторить вот что:

1. тест должен быть линейным
2. похожим на тест-кейс
3. читаться человеком
4. оперировать терминами предметной области

К чему это я?

Я сегодня просматривал код. Много разного кода. И некоторые вещи заставили меня задуматься о том, что есть вещи которые видимо стоит повторять неоднократно.

Что я хотел сказать о TDD, но всё как-то недосуг. "Дорога в тысячу ли начинается с одного шага"

Моё знакомство с "промышленным тестированием" было описано тут - http://18delphi.blogspot.ru/2013/03/blog-post.html

И с тех пор я ничего лучшего не написал.

Но это было далеко не TDD.

И не "тестирование в широком смысле этого слова".