Но получать параметры извне тоже можно. В таком случае, если запуск с нуля параметрами является нежеланным поведением (это не всегда так), то достаточно лишь сделать на это проверку:
func (s *Suite) BeforeAll(t T) {
s.casesOS := fetchOSes()
if len(s.casesOS) == 0 {
t.Fatal("at least 1 os is required")
}
}
func (s *Suite) CasesOS() []string {
return s.casesOS
}
Тогда проблема не сильно отличается от сценария, когда для цикла в табличном тесте тоже может не оказаться значений:
func Test(t *testing.T) {
cases := fetchCases() // а что если тут 0 значений?
for _, tt := range cases {
t.Run(tt.name, func(t *testing.T) { ... })
}
}
Но я могу согласиться, что, возможно, была бы полезна опция, которая делала бы это сама. Подумаю как можно улучшить этот момент, спасибо.
Вы говорите, что рефлексия у вас “в паре контролируемых мест”. На деле Testo пытается быть скрытым Spring-подобным DI-контейнером, который бесцеремонно вторгается во внутренности пользовательских структур…
…Экспортируемые поля внутри T перестают быть обычным Go-кодом
Это действительно одно из контролируемых мест. Невозможно неправильно описать T и запустить тесты.
“Шаг влево, забыл звездочку” - это единственное требование, но на самом деле IDE подскажет так не делать, потому что отсутствие звездочки вызовет стандартное предупреждение от go vet “passes lock by value” при дальнейшем использовании такого типа T. Но это больше приятный бонус.
В любом случае T предназначена исключительно для подключения плагинов. В языке с указателями есть много мест, где можно забыть звездочку и почти всегда это приведет к ошибке, как и тут. В Testo эта ошибка контролируется.
Возможно, нам повезло обойти подобную проблему, но не могу придумать или привести в пример ни один сценарий, чтобы бы конкретно этот момент вызвал трудности использования или оказался неожиданным.
Из-за этого два независимых экземпляра одного и того же плагина (например, с разной конфигурацией) внутри одной структуры T физически невозможно выразить.
Я не думаю, что есть реальный сценарий, когда необходимо иметь две регистрации одного плагина. Насколько мне известно, в Pytest, например, это тоже невозможно. Если плагин в разной конфигурации может иметь несколько (неконфликтующих) фичей, то почему бы плагину не поддерживать их в единой конфигурации? Таким образом плагин сам решает, что может конфликтовать, а что нет. Или, быть двумя разными плагинами? В общем, звучит как антипаттерн.
Но если есть примеры подобного использования, то будет интересно узнать подробнее 🤔
Axiom не сканирует структуру тестов рефлексией, …, не паникует из-за отсутствия указателей
Не считаю это проблемой, но справедливости ради, это же не так:
Не пойми неправильно, я не ставлю цель убедить использовать одно, вместо другого. В конце концов, мы же оба говорим про Open-Source и на одной стороне =)
В разных проектах и командах одни инструменты могут быть оптимальнее других. В нашем случае, Testo закрыл все былые проблемы и потому решили им поделиться со всеми. С некоторыми аргументами я не могу согласиться и решил рассказать почему. Возможно, у автора, @sound_right, тоже есть мнение на этот счет, будет интересно послушать!
Как бы то ни было, спасибо за уделенное время! Надеюсь, удалось ответить. Если будут еще вопросы, то буду рад их обсудить - мне эта тема интересна.
@Dimmur@blessyocean Спасибо большое за обратную связь и уделенное проекту / докладу время, для меня это очень ценно!
Хочу прокомментировать пару моментов.
полностью зеленый CI в мастере при молча пропущенных критичных тестах из-за банальной опечатки в регистре имени метода (CasesOs вместо CasesOS)
Согласен, подобное поведение было бы неправильным. В Testo этот момент учтен. До запуска тестов должны пройти проверки, которые иначе вызовут ошибку. Например, если нужный параметр не найден, то произойдет подобная ошибка до запуска любых тестов в сьюте:
=== RUN Test
main_test.go:15: testo: wrong param signature for (*main.Suite).TestCompile: missing (*main.Suite).CasesOS() []string for param "OS"
--- FAIL: Test
Таким образом, CI точно не будет зеленым, а лог укажет на ошибку.
Ozon официально расписался в том, что забросил allure-go на жизнеобеспечение
Мы (как мейнтейнеры Allure-Go) все еще занимаемся исправлением багов. Речь лишь о том, что не стоит более ожидать в нем нового функционала. Но это скорее не новость, а больше фиксация текущего состояния проекта. Новых фичей в нем не было уже давно, только стабилизация. Иными словами, Allure-Go не “превратился в тыкву”, просто мы рекомендуем Testo вместо Allure-Go, особенно для новых проектов.
“с Testo такого точно не повторится” - это чистой воды маркетинг. Еще как повторится, как только их новая неявная магия на рефлексии начнет сыпаться на объемах реальных компаний.
Понимаю почему так может показаться и тут важно прояснить пару моментов:
Testo довольно давно и активно используется для работы более 10 тысяч тестов в сотне команд и сервисов. По нашим наблюдениям, он намного стабильнее и гораздо гибче предшественника. Множество команд, благодаря плагинам, уже использует функционал, недоступный ранее ни в Allure-Go, ни в иных фреймворках. Так что не могу согласиться с утверждением “начнет сыпаться на объемах реальных компаний”, наш опыт говорит об обратном.
Вся магия на рефлексии происходит исключительно в паре контролируемых мест внутри фреймворка и тщательно протестирована “в бою” и юнитами (ссылка на покрытие). У пользователя не должно быть возможности сломать что-то в фреймворке.
Testo был спроектирован на основе ошибок, выявленных за 5 лет развития Allure-Go. Это был осознанный переход и мы хотели сделать инструмент, решающий эти проблемы и у которого не будет возможности устареть, благодаря плагинам. Это говоря про то, почему подобная история не должна повториться.
Я надеюсь, что удалось прояснить некоторые недопонимания. Буду рад услышать мнение на этот счет и ответить на вопросы!
Спасибо еще раз за фидбек, он помогает делать проект лучше для всех.
Во первых, спасибо за обратную связь по Allure-Go. Со многими пунктами мы и сами (мейнтейнеры Allure-Go) согласны.
Во вторых, буквально сегодня мы выложили в Open-Source новый фреймворк тестирования Testo, который решает многие хотелки, недоступные в Allure-Go.
Его главная фича это поддержка плагинов, которые могут творить с тестами практически что угодно. Например, Allure отчеты теперь просто отдельный плагин.
Привет еще раз!) Давай сразу по пунктам:
Параметры, чаще всего, объявляются статично. То есть, имея такой код, сложно случайно что-то упустить:
Но получать параметры извне тоже можно. В таком случае, если запуск с нуля параметрами является нежеланным поведением (это не всегда так), то достаточно лишь сделать на это проверку:
Тогда проблема не сильно отличается от сценария, когда для цикла в табличном тесте тоже может не оказаться значений:
Но я могу согласиться, что, возможно, была бы полезна опция, которая делала бы это сама. Подумаю как можно улучшить этот момент, спасибо.
Это действительно одно из контролируемых мест. Невозможно неправильно описать
Tи запустить тесты.“Шаг влево, забыл звездочку” - это единственное требование, но на самом деле IDE подскажет так не делать, потому что отсутствие звездочки вызовет стандартное предупреждение от
go vet“passes lock by value” при дальнейшем использовании такого типаT. Но это больше приятный бонус.В любом случае
Tпредназначена исключительно для подключения плагинов. В языке с указателями есть много мест, где можно забыть звездочку и почти всегда это приведет к ошибке, как и тут. В Testo эта ошибка контролируется.Возможно, нам повезло обойти подобную проблему, но не могу придумать или привести в пример ни один сценарий, чтобы бы конкретно этот момент вызвал трудности использования или оказался неожиданным.
Я не думаю, что есть реальный сценарий, когда необходимо иметь две регистрации одного плагина. Насколько мне известно, в Pytest, например, это тоже невозможно. Если плагин в разной конфигурации может иметь несколько (неконфликтующих) фичей, то почему бы плагину не поддерживать их в единой конфигурации? Таким образом плагин сам решает, что может конфликтовать, а что нет. Или, быть двумя разными плагинами? В общем, звучит как антипаттерн.
Но если есть примеры подобного использования, то будет интересно узнать подробнее 🤔
Не считаю это проблемой, но справедливости ради, это же не так:
Тут сканирование через рефлексию
Тут паника из-за отсутствия указателей
Не пойми неправильно, я не ставлю цель убедить использовать одно, вместо другого. В конце концов, мы же оба говорим про Open-Source и на одной стороне =)
В разных проектах и командах одни инструменты могут быть оптимальнее других. В нашем случае, Testo закрыл все былые проблемы и потому решили им поделиться со всеми. С некоторыми аргументами я не могу согласиться и решил рассказать почему. Возможно, у автора, @sound_right, тоже есть мнение на этот счет, будет интересно послушать!
Как бы то ни было, спасибо за уделенное время! Надеюсь, удалось ответить. Если будут еще вопросы, то буду рад их обсудить - мне эта тема интересна.
Привет! Я автор Testo.
@Dimmur @blessyocean Спасибо большое за обратную связь и уделенное проекту / докладу время, для меня это очень ценно!
Хочу прокомментировать пару моментов.
Согласен, подобное поведение было бы неправильным. В Testo этот момент учтен. До запуска тестов должны пройти проверки, которые иначе вызовут ошибку. Например, если нужный параметр не найден, то произойдет подобная ошибка до запуска любых тестов в сьюте:
Таким образом, CI точно не будет зеленым, а лог укажет на ошибку.
Если интересно, вот еще примеры подобных проверок.
Мы (как мейнтейнеры Allure-Go) все еще занимаемся исправлением багов. Речь лишь о том, что не стоит более ожидать в нем нового функционала. Но это скорее не новость, а больше фиксация текущего состояния проекта. Новых фичей в нем не было уже давно, только стабилизация. Иными словами, Allure-Go не “превратился в тыкву”, просто мы рекомендуем Testo вместо Allure-Go, особенно для новых проектов.
Понимаю почему так может показаться и тут важно прояснить пару моментов:
Testo довольно давно и активно используется для работы более 10 тысяч тестов в сотне команд и сервисов. По нашим наблюдениям, он намного стабильнее и гораздо гибче предшественника. Множество команд, благодаря плагинам, уже использует функционал, недоступный ранее ни в Allure-Go, ни в иных фреймворках. Так что не могу согласиться с утверждением “начнет сыпаться на объемах реальных компаний”, наш опыт говорит об обратном.
Вся магия на рефлексии происходит исключительно в паре контролируемых мест внутри фреймворка и тщательно протестирована “в бою” и юнитами (ссылка на покрытие). У пользователя не должно быть возможности сломать что-то в фреймворке.
Testo был спроектирован на основе ошибок, выявленных за 5 лет развития Allure-Go. Это был осознанный переход и мы хотели сделать инструмент, решающий эти проблемы и у которого не будет возможности устареть, благодаря плагинам. Это говоря про то, почему подобная история не должна повториться.
Я надеюсь, что удалось прояснить некоторые недопонимания. Буду рад услышать мнение на этот счет и ответить на вопросы!
Спасибо еще раз за фидбек, он помогает делать проект лучше для всех.
Привет!
Во первых, спасибо за обратную связь по Allure-Go. Со многими пунктами мы и сами (мейнтейнеры Allure-Go) согласны.
Во вторых, буквально сегодня мы выложили в Open-Source новый фреймворк тестирования Testo, который решает многие хотелки, недоступные в Allure-Go.
Его главная фича это поддержка плагинов, которые могут творить с тестами практически что угодно. Например, Allure отчеты теперь просто отдельный плагин.
Скоро расскажу про него подробнее на нашем QA Meetup’е, а пока можно изучить его репозиторий на GitHub’е: https://github.com/ozontech/testo