Добавить атрибуты тестов, как в других тестовых фреймворках

[artbear]

Добавить атрибуты тестов, как в других тестовых фреймворках (JUnit, NUnit и т.п.)

Различные атрибуты тестов пригодятся для классификации тестов различными способами и для более удобного вывода отчетов о тестировании.

Например, атрибуты могут сказать, в какую фичу, юзер-стори входит тест, к какому типу относится (ГУИ, интеграционный, тест настроек в рабочей базе и т.п.)

Возможная реализация:

• или в параметрах теста указывается коллекция/структура с атрибутами теста

  • c помощью Снегопата можно автоматизировать сбор инфы об атрибутах, если атрибуты указывать в комментариях в спец.виде типа

    //@Feature("Заказ товаров у поставщика")
    //@Story("Оплата заказа")
    

• или дополнительное описание в специальном методе теста (ПолучитьАтрибутыТестов)

[artbear]

Еще интересный вариант предложил Евгений Сосна
аналог реализации тестов на питоне для Allure

ЮТест.Allure.Step("ОчереднойШаг") или ЮТест.Allure.Feature("ОчереднойШаг")

Можно сделать с использованием плагинов.

Пример на питоне:

allure.star_suite('demo')
allure.start_case('test_one')
allure.stop_case(Status.PASSED)
allure.start_case('test_two')
allure.start_step('a demo step')
allure.attach('some file', 'a quick brown fox..', AttachmentType.TEXT)
allure.stop_step()
allure.stop_case(Status.FAILED, 'failed for demo', 'stack trace goes here')
allure.stop_suite() # this writes XML into ./reports

[artbear]

И у меня родился простой вариант без плагинов 👍

• ЮТест.Шаг("НужныйШаг")
• или ЮТест.ДобавитьАтрибут("Шаг", "НужныйШаг")
• или ЮТест.ДобавитьАтрибут("Фича", "Эпик1")

Последний вариант с ДобавитьАтрибут пока нравится больше всего 👍
он наиболее прост с точки зрения реализации

[pumbaEO]

Тогда, если есть группа тестов привязанных к "Эпик" , то в случаии падения одного теста, вся "Эпик" помечается упавшей.
Есть ли смысл проводить остальные тесты для этой Эпик?

[artbear]

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

Не у всех есть Снегопат - значит те у кого его нет будут лишены функциональности.

Может тебе расширить сигнатуру метода РегистрацииТеста дополнительными параметрами Story, Feature.
Для того чтобы делать 2-ух уровневое дерево.

То есть два тогда мы имеем примерно такое

ВсеТесты.Добавить("ТестДолжен_ПроверитьСозданиеИгры", "История создания игры", "Обработка.Змейка запуск и настройка");

Но ВсеТесты у нас массив. Было бы классно добавить метод юТест.ЗарегистрироватьТест(ИмяМетода, ИмяИстории, ИмяФункции)
Но тогда как обеспечить обратную совместимость.

Пока такие мысли.

[artbear]

Да, я также уже думал о расширении метода регистрации тестов ( ПолучитьСписокТестов и ВсеТесты.Добавить ).

1. xUnitFor1C давно уже умеет работать не с простым массивов имен тестов, но и сложными параметрическими тестами (передаем не имя теста, а параметры теста).
   На этом основаны всякие параметрические тесты типа ОткрытиеВсехФормКонфигурации, ПрогонТестовДляРазныхПользователей и т.п.
   Атрибуты сюда очень легко загнать.

Параметры = Новый Структура("ПредставлениеТеста, ИмяТеста, Транзакция, Параметр", "Тест с опциями", "ТестСОпциями", Истина, "тест представления");
ВсеТесты.Добавить(Параметры);

1. Также думал о спец.методе ЮТест.ДобавитьТест(ИмяМетода, Опции, Атрибуты), который будет действовать только на момент создания тестов (внутри ПолучитьСписокТестов)

В обоих случаях совместимость остается.
Мне больше нравится второй вариант, он более ООП :)

Тут еще большой вопрос реализации - т.к. дерево возможно в несколько уровней (например, Эпик, ЮзерСтори, ТестКейс, простой тест), нужно переделывать работу с деревом одновременно и для ОФ и УФ. Конечно, реализация - это следующий шаг.

Поэтому я и создал issue для обсуждения, чтобы совместно выработать общий шаблон :)

ЗЫ Леша, я про Снегопат не понял, он здесь вроде никак не участвует :)

Дерево возможно в несколько уровней в систему управления задачами. Но сейчас в основном в тестовых фреймворках используется 2-ух уровневый - точнее 3-ёх уровневый

Feature
Story
Test

А в системах управления задачами сейчас такой бардак в терминологии, что я бы на них не равнялся. Предлагаю пока остаться в этом количестве уровней.

Про параметризируемые я понял. Не очень читаемо будет, но в принципе зато наше штатное поведение.

[artbear]

Да, конечно, 3-х уровней хватит, согласен.

Над интерфейсом еще можно подумать -
например, ЮТест.ДобавитьШаг(ИмяМетода, Опции, История, Фича = "")

[artbear]

Наверное, так еще лучше
ЮТест.ДобавитьШаг(ИмяМетода, Опции, ИмяШага, История, Фича = "")

Использую "Шаг" для обозначения того, что этот тест будет выполняться в составе история/сценария и для него не нужно гарантировать изолированность, как сделано для простых функциональных тестов, а нужно, наоборот, сделать шаги истории/сценария связанными.