вторник, 15 ноября 2011 г.

Есть вопросы

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

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

Я и Коллега2: - Слово контейнер реально неудобное :(((
Коллега1: - Я же говорил!
Я и Коллега2: - Твои версии на этот счет?
Коллега1: - Эээ...
Я: - Раз версий нет - будем пользоваться термином модель данных объекта тестируемой системы

Вот вы сейчас, наверное, скажете
- Мне бы ваши проблемы!
Тоогда я, наверное, отвечу:
- Уж какие есть.
А потом спрошу:
- Но у вас наверняка есть свои версии на все эти счета?

Нет, серьезно. В любой автоматизированной системе управления должно быть представление о управляемом объекте, некая ее модель.
А мы должны получать информацию о объекте сравнивать ее с информацией о модели объекта.

И всю эту хрень надо как-то называть.
Мало того, я сознательно допускаю некую неточность, так как мы храним значения параметров объекта, а понятие модель данных подразумевает еще и аспект манипуляции...

Итак, если вы понимаете, о чем я, то скажите:

- Какими определениями/терминами пользуетесь для обозначения модели тестируемого объекта в тестах?

P.S. Прям потянуло перечитать курс лекций по ТАУ
P.P.S. Наш selenium фреймворк ведь можно описать как замкнутую САУ дискретного воздействия, без обратной связи, неадаптивную, детерминированную, программную, многомерную, гы...

Альбом: randompics4lj

5 комментариев:

  1. У меня одно время был класс TestObjectDescriptor - душевный скрежет при создании был заглушен доводами типа "в данном контексте привычное значение термина ослабевает..." и "чувак у тебя мало время, харэ тупить над названием". Недавно последняя часть была удалена - но правда основной целью было улучшение читаемости +)

    В свою очередь, за исключением устоявшегося использования термина(причем наиболее часто как сокращенная фраза), ничего против корректности смысловой нагрузки не имею до сих пор.

    ОтветитьУдалить
  2. Т.е. вы положили болт на типизацию объектов и иерархию типизации?
    А в целом я за тоталитаризм... назначить и все. Как больше нравится...

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

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

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

    ОтветитьУдалить