Go, я создал: интегрируем Allure в Go красиво

[Tan_tan]

Ухты, интересно)) Какие-то подводные камни при использовании библиотеки, ограничения? Нет ли проблем с параллелизацией тестов с вашей библиотекой?

[koodeex]

Привет!

Хороший вопрос, постараюсь ответить развернуто :)

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

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

Также, если важно запускать отдельные тесты параллельно, есть функционал из пакета runner, который позволяет запускать тесты параллельно между собой.

То есть, решить эту проблему на уровне имплементации тестов более чем реально и даже никаких костылей не понадобится :)

Причины же проблем параллелизации в рамках тест-сьюта достаточно глубокие, и строится вокруг спецфики работы с тестовым контекстом (указатель testing.T). Что в testify, что в нашей allure-go, этот самый указатель один на сьют, от которого и запускаются все тесты под капотом. Асинхронная работа приводит к тому что несколько рутин одновременно пытаются изменить состояние исходного указателя testing.T, от которого и был запущен тест, что приводит к конфликтам и ошибкам, описанным в исходной ишью.

Помимо прочего, в скором времени будет большой апдейт, который значительно улучшит работу с асинхроном :)

[koodeex]

@Tan_tan, вот тут драфт-ПР по апдейту, о котором я говорил. Держу в курсе :)

Немного изменили интерфейсы, но это помогло решить проблемы с асинхронным запуском тестов.

Вкратце, основные изменения можно описать так:

• изменение сигнатур тестов в suite'ах. теперь обязательно требуется прокидывать интерфейс provider.T в тесты

func (s *SomeSuite) TestSome(t provider.T) {
  t.Title("My Test")
  ...
}

• изменение сигнатур в анонимных функциях шагов - теперь обязательно нужно прокидывать контекст шага (интерфейс provider.StepCtx)

func (s *SomeSuite) TestSome(t provider.T) {
 ...
 t.WithNewStep("step name", func (ctx provider.StepCtx)) {
  ctx.WithNewParameters("param name", "param value")
  ctx.WithNewStep("sub step name", func(ctx provider.StepCtx)) {
    ...
  }
  ...
 }
  ...
}

• все взаимодействия с аллюром перенесены из структуры suite в интерфейс provider.T

• исправлены асинхронные запуски тестов в рамках suite

• добавлена возможность запускать асинхронные шаги

func (s *SomeSuite) TestSome(t provider.T) {
  ...
  t.WithNewAsyncStep("step name", func(ctx StepCtx)) {
    // эта анонимная функция отработает в дочернем рутине теста
    ...
  }
  ...
}

• добавлены обертки для ассертов. Теперь можно оборачивать проверки testify в шаги нативно с помощью пакета assert/require модуля framework. список доступный проверок можно посмотреть в интерфейсе provider.Assert (со временем расширим пул доступных проверок)

  Примечание: require-проверки (aka hard-assert, или проверки, убивающие тестовый рутин) не рекомендуется использовать в асинхронных степах во избежание утери данных о состоянии этих проверок. для таких шагов лучше использовать soft-assert'ы

func (s *SomeSuite) TestSome(t provider.T) {
  // проверка будет добавлена в отчет как новый шаг
  t.Require().Equal(1, 1) 
  t.WithNewStep("require demo", func(ctx StepCtx)) {
    // проверка будет добавлена как sub step в родительский шаг require demo
    ctx.Require().Nil(nil)
  }
  t.WithNewAsyncStep("assert demo", func (ctx StepCtx)) {
	  // проверка будет добавлена как sub step в родительский шаг assert demo
    ctx.Asserts().NotEqual(0, 1)
  }
}

• В пакет runner добавлена возможность использовать Before/After all хуки

• в объекте runner теперь обязательно нужно вызывать метод RunTests для запуска добавленных в него тестов

• саб модуль provider теперь часть саб модуля framework

[dmitry_remezov]

Привет! Вы упоминаете про минимальный порог вхождения. Это про сами тесты на Go? Или про Allure?)

[koodeex]

Добрый день!

Это про Go в целом и тесты в частности.)

На рынке сейчас очень много специалистов, основной стек которых строится вокруг Java, Python, JS или C#. Не все готовы сходу переучиваться, хотя порог вхождения в Go достаточно низкий, - многих пугает наличие указателей, к примеру.

Однако, последние полгода показали, что никаких проблем подтягивание до нужного уровня Go не вызывает, ровно как и обучение. :)

[dmitry_remezov]

Честно сказать, не вижу проблемы в переходе с одного С-подобного языка на другой в плане автотестов. Фреймворки везде +/- одинаковые. Просто Java ну прям очень универсальная. На ней не надо писать огромную кучу велосипедов. Правда иногда проигрывает в скорости по отношению к нативным тестам, например. На сколько оправдано переходить с Java на Go, на Ваш взгляд?

[koodeex]

Мне сложно дать однозначный и простой ответ, не зная подробностей Вашего проекта) Однако, если опустить полемику - быстрый ответ звучит так: если у Вас разработка на Go - определенно точно стоит как минимум попробовать.

На мой взгляд - оптимальный вариант развития автотестов, это когда вы можете с разработкой говорить на одном языке. Уровень всех специалистов разный и всегда приятно иметь возможность посоветоваться по каким то вопросам, связанным с кодом, с людьми, которые занимаются именно разработкой. Плюс, общая инфраструктура. Готовые докер-образы, например, или линты. Общее ревью, стандарты.

То есть: если Ваша разработка имеет в основном стеке Java, то круто, когда у Вас тесты на Java. Если на Go - здорово, можно попробовать посмотреть в эту сторону.

Если абстрагироваться от общего стека - вопрос встает иначе: "На какой платформе будет дешевле поднять и поддерживать тесты?". И тут уже надо смотреть на рынок, на уровень специалистов, на инфраструктуру и даже стоить учесть уровень заинтересованности (оно же насколько большое в этом пространстве коммьюинти).

Как пример - на C/С++ тоже множество готовых инструментов, но специалистов QA, которые пишут автоматизацию на C/C++ не очень много.

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

Я бы советовал Вам попробовать начать, изучить тему. Если Вы поймете, что преимущества, которые дает Go для вас имеют больший вес, чем минусы - тогда, я думаю, что можно и перейти :)