Заметки о тестировании №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)}" "Построить предварительный просмотр и сравнить с эталоном" 

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

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

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

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

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

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

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

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