Я: - Так вот, мы передаем контейнер в тот метод
Коллега1: - Мне не нравится слово контейнер, в программировании оно значит совсем другое
Я: - В %предыдущий_проект% мы с Коллега2 пользовались этим словом и привыкли.
Коллега1: - Мне оно все равно не нравится, давайте использовать слово метаобъект
Коллега2: - У нас в системе(тестируемой) есть метаданные и метаклассы, мы запутаемся
Я: - Правильно, запутаемся. У нас демократия поэтому будем пользоваться словом контейнер
Я и Коллега2: - Слово контейнер реально неудобное :(((
Коллега1: - Я же говорил!
Я и Коллега2: - Твои версии на этот счет?
Коллега1: - Эээ...
Я: - Раз версий нет - будем пользоваться термином модель данных объекта тестируемой системы
Вот вы сейчас, наверное, скажете
- Мне бы ваши проблемы!
Тоогда я, наверное, отвечу:
- Уж какие есть.
А потом спрошу:
- Но у вас наверняка есть свои версии на все эти счета?
Нет, серьезно. В любой автоматизированной системе управления должно быть представление о управляемом объекте, некая ее модель.
А мы должны получать информацию о объекте сравнивать ее с информацией о модели объекта.
И всю эту хрень надо как-то называть.
Мало того, я сознательно допускаю некую неточность, так как мы храним значения параметров объекта, а понятие модель данных подразумевает еще и аспект манипуляции...
Итак, если вы понимаете, о чем я, то скажите:
- Какими определениями/терминами пользуетесь для обозначения модели тестируемого объекта в тестах?
P.S. Прям потянуло перечитать курс лекций по ТАУ
P.P.S. Наш selenium фреймворк ведь можно описать как замкнутую САУ дискретного воздействия, без обратной связи, неадаптивную, детерминированную, программную, многомерную, гы...
 |
| Альбом: randompics4lj |
У меня одно время был класс TestObjectDescriptor - душевный скрежет при создании был заглушен доводами типа "в данном контексте привычное значение термина ослабевает..." и "чувак у тебя мало время, харэ тупить над названием". Недавно последняя часть была удалена - но правда основной целью было улучшение читаемости +)
ОтветитьУдалитьВ свою очередь, за исключением устоявшегося использования термина(причем наиболее часто как сокращенная фраза), ничего против корректности смысловой нагрузки не имею до сих пор.
Т.е. вы положили болт на типизацию объектов и иерархию типизации?
ОтветитьУдалитьА в целом я за тоталитаризм... назначить и все. Как больше нравится...
Ну во-первых положиЛ - я сам себе и диктатор и народные массы. На самом деле минусов гораздо больше в подобном выражении, нежели реального профита. Свои ошибки в отношении сущностей не своевременно замечаешь, да и наверно не всегда; некоторые костыли вполне убедительно удается отстоять наиболее удобные "механизмы" в текущей ситуации. Да и вообще вариться в собственном соку не айс.
ОтветитьУдалитьКасательно типизации подход такой - рассматриваем мы не объект, не модель(в широком смысле) его - а некоторое описание(отсюда и пошло descriptor). На первый взгляд может показаться сущей ересью, потому что система оперирует объектами, пользователь ими же - почему бы не захардкорить пару атрибутов, а может даже и метод? Ответ у меня такой - потому что это будет либо дублированием работы системы, либо действий пользователей. Во втором случае, так же как и в первом, но менее явно, "нехорошо" заключается в том, что мы под описанием объекта потенциально скрываем шаги, которые хорошо бы отобразить в сценарии. Подход радикальный, полное придерживание которого приведет к истощению и потери ценности автоматизированных тестов как программного продукта - мне так и снятся кошмары, где надо рефакторить портянки тестовых сценариев=)
Теперь больше конкретики. Во-перых особенность продукта в том, что в системе как таковой куча типов. В довесок к этому возможность настройки и создания своих. Во-вторых пока идет покрытие достаточно общих механизмов, возможно поэтому проблемы типизации "описания тестовых сущностей" не так остры. Технически иерархия объектов как сущностей системы ограничена базовым интерфейсом(идентификатор - пусть то внешний объект или внутрисистемный хак, как то мы должны его идентифицировать, и допустим название) и классом с общими параметрами - ууид, родитель, название, список атрибутов(вот большинство атрибутов в классы забиты как раз). Последний в свою очередь порождает чисто технические подклассы - по типу инициализации(lazy или об объекте знаем все заранее). И этого хватает пока что удивительно! Правда есть одно но - вне контекста тестового сценария мы имеем слабое представление о типе объекта. Хотя это вполне укладывается в немного утрированный подход разделения логики тестов от параметров.
Против воссоздания иерархии объектов тестируемой системы в автоматизированных тестах выступает еще и то, что в рассмотрении тестов как независимых процессов иерархия начинает казаться избыточной.
А вообщем у меня закрадывается мысль, что потребность в типизации возникает при тестировании сложных бизнес-действий(или даже цепочек) при отсутствии(хотя бы частичном) корректно спроектированных тестов, не подлежащих повторному использованию. Лечим типизацию проектированием сценариев - час от часу не легче +)
Предлагаю как нибудь собраться и обсудить код да и вообще. Есть несколько мыслей.
ОтветитьУдалитьaccepted!
ОтветитьУдалить