Есть вопросы

[w_bf]

Диалог о системе тестирования:

Я: - Так вот, мы передаем контейнер в тот метод
Коллега1: - Мне не нравится слово контейнер, в программировании оно значит совсем другое
Я: - В %предыдущий_проект% мы с Коллега2 пользовались этим словом и привыкли.
Коллега1: - Мне оно все равно не нравится, давайте использовать слово метаобъект
Коллега2: - У нас

Comments

[vaha_ekb]

Ну во-первых положиЛ - я сам себе и диктатор и народные массы. На самом деле минусов гораздо больше в подобном выражении, нежели реального профита. Свои ошибки в отношении сущностей не своевременно замечаешь, да и наверно не всегда; некоторые костыли вполне убедительно удается отстоять наиболее удобные "механизмы" в текущей ситуации. Да и вообще вариться в собственном соку не айс.
Касательно типизации подход такой - рассматриваем мы не объект, не модель(в широком смысле) его - а некоторое описание(отсюда и пошло descriptor). На первый взгляд может показаться сущей ересью, потому что система оперирует объектами, пользователь ими же - почему бы не захардкорить пару атрибутов, а может даже и метод? Ответ у меня такой - потому что это будет либо дублированием работы системы, либо действий пользователей. Во втором случае, так же как и в первом, но менее явно, "нехорошо" заключается в том, что мы под описанием объекта потенциально скрываем шаги, которые хорошо бы отобразить в сценарии. Подход радикальный, полное придерживание которого приведет к истощению и потери ценности автоматизированных тестов как программного продукта - мне так и снятся кошмары, где надо рефакторить портянки тестовых сценариев=)
Теперь больше конкретики. Во-перых особенность продукта в том, что в системе как таковой куча типов. В довесок к этому возможность настройки и создания своих. Во-вторых пока идет покрытие достаточно общих механизмов, возможно поэтому проблемы типизации "описания тестовых сущностей" не так остры. Технически иерархия объектов как сущностей системы ограничена базовым интерфейсом(идентификатор - пусть то внешний объект или внутрисистемный хак, как то мы должны его идентифицировать, и допустим название) и классом с общими параметрами - ууид, родитель, название, список атрибутов(вот большинство атрибутов в классы забиты как раз). Последний в свою очередь порождает чисто технические подклассы - по типу инициализации(lazy или об объекте знаем все заранее). И этого хватает пока что удивительно! Правда есть одно но - вне контекста тестового сценария мы имеем слабое представление о типе объекта. Хотя это вполне укладывается в немного утрированный подход разделения логики тестов от параметров.
Против воссоздания иерархии объектов тестируемой системы в автоматизированных тестах выступает еще и то, что в рассмотрении тестов как независимых процессов иерархия начинает казаться избыточной.

А вообщем у меня закрадывается мысль, что потребность в типизации возникает при тестировании сложных бизнес-действий(или даже цепочек) при отсутствии(хотя бы частичном) корректно спроектированных тестов, не подлежащих повторному использованию. Лечим типизацию проектированием сценариев - час от часу не легче +)

[w_bf]

Предлагаю как нибудь собраться и обсудить код да и вообще. Есть несколько мыслей.

[vaha_ekb]

accepted!