Привет! Рад, что тебе понравилось) Использование моков подходит под описание "тесты со сценарием", так что я предлагаю использовать функции performAction и verifyResult в первой сделай мок и выполни запрос, а во второй проверь результат, в целом мок не нечто сложное и тестирование с ними практически ничем не отличается от других тестовых кейсов
Отвечу немного наперед. Если вопрос касается того, что я разделяю ответственность внутри тестовой функции, но объединяю тесты и бенчмарки в одну функцию, то отвечу так. Разделять ответственность внутри теста это вклад в повышение стабильности тестов, что бы при добавлении новых кейсов не было коллизий и данные не могли пересечься между тестами. Объединение тестов и бенчмарков даже потенциально было спорным решением, но в тоже время это было вызовом и именно этот подход я хотел бы использовать при разработке генератора, так как я думаю, что сюда очень хорошо ляжет шаблон для кодогенерации.
Расскажи пожалуйста подробно, что тебя смущает, это очень важно для меня)
Привет! Спасибо за обратную связь) Уточни пожалуйста, ты имеешь ввиду, что хорошая практика разбивать тесты и бенчмарки или что-то другое и почему преимущества теряются? Я с радостью подумаю как это пофиксить)
Привет! Спасибо за уделенное время) Посмотрел на сгенерированный код goland и сравнил его со своим, мнение сугубо личное и я готов его пересмотреть, если я объективно не прав:
Плюсы кодгена. Отмечу простоту, эти тесты пря идеально подойдут для элементарных тестов, возможно именно такой простоты я добивался при продумывании своего шаблона. Нельзя забывать что этот подход ясно показывает, какие данные входят в функцию и что ожидается на выходе.
Минусы кодгена. Как, мне кажется, сразу заметно, что сгенерированная часть не такая гибкая. Её менее удобно использовать для сложных сценариев тестирования, где нужно проверять много аспектов работы функции.
Преимущества предложенного мной шаблона. Можно легко добавлять новые шаги в тест, такие как подготовка данных или дополнительные проверки. Как мне кажется, модульность и разделение ответственности компонентов позволяет легко модифицировать или переиспользовать код.
Минусыпредложенного мной шаблона. Сейчас стреляю себе в ногу, но не могу быть не объективным. Очевидно, что мой паттерн может оказаться более сложный для понимания и настройки по сравнению с кодген шаблоном, который предоставляет нам goland, а так же он может быть избыточным при тестировании простых функций.
Как итог могу сказать, мне кажется, что предложенный шаблон лучше работает со сложными сценариями и лучше масштабируется под сложные проверки. Конечно, можно сделать проще, можно кодгенить, а мне хотелось предложить нечто читаемое и самое главное, я хотел это нечто сделать читаемым после масштабирования. Ну и по итогу мы собрали паттерн в универсальную тест/бенчмарк функцию.
Концепция генератора пока прорабатывается. Хочется, конечно, автоматическую генерацию тестов, но это фактически сделать сложно, если вообще возможно, так как анализировать логику программы очень сложно.
Если абстрагироваться от хотелок и посмотреть трезво, то следующими шагами я вижу
написание утилиты для создания тестового файла с базовым шаблоном, а так же добавление базового шаблона, если файл уже существует. Утилита вряд ли будет отвечать каким-либо требованиям используемым в коммерческой разработке, но она создаст базу для дальнейшего масштабирования
расширение утилиты в анализатор с возможностью добавления тестовой функции на базе шаблона для каждого метода из директории в тестовый файл. Предполагается, что на данном этапе в тестовые и ожидаемые значения будут подставляться типы, используемые в аргументах и возвращаемых значения тестируемого метода. Это не совсем точно из-за возможности использования данных из типа, которому принадлежит метод, но пока подробно не прорабатывал этот вопрос. Хочется, что бы по итогу этого шага утилита генерировала шаблоны, в которые останется только внести ожидаемые и тестовые значения и немного поправить сценарий, так как примитивная генерация сценарий + assert.Equal() уже должна присутствовать на данной стадии
Данный шаблон регулярно запускается с большим количеством тестов. стейдж проходит не сильно медленнее тестов написаных без шаблона, так как хорошо написанные тесты предполагают всё те же этапы.
Привет! Пост прикольный, но хотелось бы чуть больше конкретики о том, какой профит я получу если буду использовать практики изложенные в посте.
пример
Роутеры - использование роутеров упрощает маршрутизацию, улучшает читаемость и структуру кода, поддерживает middleware, и делает API более гибкими и масштабируемыми, что особенно важно для крупных проектов.
Jet templates - высокопроизводительный и гибкий движок шаблонов. Он обеспечивает быстрый рендеринг и компиляцию шаблонов в Go-код, поддерживает гибкий синтаксис, автоматическое экранирование данных для безопасности, а также легко расширяется пользовательскими функциями и интегрируется с Go-фреймворками.
Middleware - промежуточный код, который выполняется до того, как начнёт выполняться ваш основной код. middleware может использоваться для выполнения различных задач, таких как аутентификация и авторизация пользователей, обработка ошибок, логирование запросов, управление сессиями и кэширование данных. Он может модифицировать запросы и ответы, добавлять новые данные или даже предотвращать выполнение основного кода, если это необходимо.
Просто хочу сказать Спасибо за такой прекрасный материал, именно таких подробных статей иногда не хватает для изучения нужных технологий, ещё раз спасибо!
Забавно, что я буквально 10 минут назад читал твои комментарии у парнишки, который собирал прибор для тестирования плат. Ты там скидывал фотографию и описание своего устройства, думаю, было бы интересно почитать и опа)
Привет! Я может что-то не догоняю, но хотелось бы уточнить
Мы же можем так вернуть ошибку или ты что-то другое имел ввиду?
Привет! Рад, что тебе понравилось)
Использование моков подходит под описание "тесты со сценарием", так что я предлагаю использовать функции
performActionиverifyResultв первой сделай мок и выполни запрос, а во второй проверь результат, в целом мок не нечто сложное и тестирование с ними практически ничем не отличается от других тестовых кейсовОтвечу немного наперед. Если вопрос касается того, что я разделяю ответственность внутри тестовой функции, но объединяю тесты и бенчмарки в одну функцию, то отвечу так. Разделять ответственность внутри теста это вклад в повышение стабильности тестов, что бы при добавлении новых кейсов не было коллизий и данные не могли пересечься между тестами. Объединение тестов и бенчмарков даже потенциально было спорным решением, но в тоже время это было вызовом и именно этот подход я хотел бы использовать при разработке генератора, так как я думаю, что сюда очень хорошо ляжет шаблон для кодогенерации.
Расскажи пожалуйста подробно, что тебя смущает, это очень важно для меня)
Привет! Спасибо за обратную связь)
Уточни пожалуйста, ты имеешь ввиду, что хорошая практика разбивать тесты и бенчмарки или что-то другое и почему преимущества теряются? Я с радостью подумаю как это пофиксить)
Привет! Спасибо за уделенное время)
Посмотрел на сгенерированный код goland и сравнил его со своим, мнение сугубо личное и я готов его пересмотреть, если я объективно не прав:
Плюсы кодгена. Отмечу простоту, эти тесты пря идеально подойдут для элементарных тестов, возможно именно такой простоты я добивался при продумывании своего шаблона. Нельзя забывать что этот подход ясно показывает, какие данные входят в функцию и что ожидается на выходе.
Минусы кодгена. Как, мне кажется, сразу заметно, что сгенерированная часть не такая гибкая. Её менее удобно использовать для сложных сценариев тестирования, где нужно проверять много аспектов работы функции.
Преимущества предложенного мной шаблона. Можно легко добавлять новые шаги в тест, такие как подготовка данных или дополнительные проверки. Как мне кажется, модульность и разделение ответственности компонентов позволяет легко модифицировать или переиспользовать код.
Минусы предложенного мной шаблона. Сейчас стреляю себе в ногу, но не могу быть не объективным. Очевидно, что мой паттерн может оказаться более сложный для понимания и настройки по сравнению с кодген шаблоном, который предоставляет нам goland, а так же он может быть избыточным при тестировании простых функций.
Как итог могу сказать, мне кажется, что предложенный шаблон лучше работает со сложными сценариями и лучше масштабируется под сложные проверки. Конечно, можно сделать проще, можно кодгенить, а мне хотелось предложить нечто читаемое и самое главное, я хотел это нечто сделать читаемым после масштабирования. Ну и по итогу мы собрали паттерн в универсальную тест/бенчмарк функцию.
Привет! Спасибо за внимание к статье)
Концепция генератора пока прорабатывается. Хочется, конечно, автоматическую генерацию тестов, но это фактически сделать сложно, если вообще возможно, так как анализировать логику программы очень сложно.
Если абстрагироваться от хотелок и посмотреть трезво, то следующими шагами я вижу
написание утилиты для создания тестового файла с базовым шаблоном, а так же добавление базового шаблона, если файл уже существует. Утилита вряд ли будет отвечать каким-либо требованиям используемым в коммерческой разработке, но она создаст базу для дальнейшего масштабирования
расширение утилиты в анализатор с возможностью добавления тестовой функции на базе шаблона для каждого метода из директории в тестовый файл. Предполагается, что на данном этапе в тестовые и ожидаемые значения будут подставляться типы, используемые в аргументах и возвращаемых значения тестируемого метода. Это не совсем точно из-за возможности использования данных из типа, которому принадлежит метод, но пока подробно не прорабатывал этот вопрос. Хочется, что бы по итогу этого шага утилита генерировала шаблоны, в которые останется только внести ожидаемые и тестовые значения и немного поправить сценарий, так как примитивная генерация сценарий + assert.Equal() уже должна присутствовать на данной стадии
Данный шаблон регулярно запускается с большим количеством тестов. стейдж проходит не сильно медленнее тестов написаных без шаблона, так как хорошо написанные тесты предполагают всё те же этапы.
Привет! Пост прикольный, но хотелось бы чуть больше конкретики о том, какой профит я получу если буду использовать практики изложенные в посте.
пример
Роутеры - использование роутеров упрощает маршрутизацию, улучшает читаемость и структуру кода, поддерживает middleware, и делает API более гибкими и масштабируемыми, что особенно важно для крупных проектов.
Jet templates - высокопроизводительный и гибкий движок шаблонов. Он обеспечивает быстрый рендеринг и компиляцию шаблонов в Go-код, поддерживает гибкий синтаксис, автоматическое экранирование данных для безопасности, а также легко расширяется пользовательскими функциями и интегрируется с Go-фреймворками.
Middleware - промежуточный код, который выполняется до того, как начнёт выполняться ваш основной код. middleware может использоваться для выполнения различных задач, таких как аутентификация и авторизация пользователей, обработка ошибок, логирование запросов, управление сессиями и кэширование данных. Он может модифицировать запросы и ответы, добавлять новые данные или даже предотвращать выполнение основного кода, если это необходимо.
Просто хочу сказать Спасибо за такой прекрасный материал, именно таких подробных статей иногда не хватает для изучения нужных технологий, ещё раз спасибо!
Это очень круто)
Забавно, что я буквально 10 минут назад читал твои комментарии у парнишки, который собирал прибор для тестирования плат. Ты там скидывал фотографию и описание своего устройства, думаю, было бы интересно почитать и опа)