Comments 10
Очень интересно написано)
Я хоть и c++ разработчик, но мы все стараемся упросить себе жизнь, где unit тесты так же занимает свою часть.
Очень интересно узнать и подсветить пару моментов.
1) Какой именно функционал генерации тестов вы хотите реализовать? Они буду генерировать тесты на основе существующего кода и генерации тестовых данных или как-то иначе. Есть ли уже какие-то идеи как хотите это сделать?
2) пробовали ли запускать при большом количестве тестов /тестовых данных. На сколько сильно результат при этом ухудшается. Конечно же подождать минуту иную не проблема, но интересно послушать были ли подобные замеры. Потому что в вашем примере отличия не сильно велики)
Привет! Спасибо за внимание к статье)
Концепция генератора пока прорабатывается. Хочется, конечно, автоматическую генерацию тестов, но это фактически сделать сложно, если вообще возможно, так как анализировать логику программы очень сложно.
Если абстрагироваться от хотелок и посмотреть трезво, то следующими шагами я вижу
написание утилиты для создания тестового файла с базовым шаблоном, а так же добавление базового шаблона, если файл уже существует. Утилита вряд ли будет отвечать каким-либо требованиям используемым в коммерческой разработке, но она создаст базу для дальнейшего масштабирования
расширение утилиты в анализатор с возможностью добавления тестовой функции на базе шаблона для каждого метода из директории в тестовый файл. Предполагается, что на данном этапе в тестовые и ожидаемые значения будут подставляться типы, используемые в аргументах и возвращаемых значения тестируемого метода. Это не совсем точно из-за возможности использования данных из типа, которому принадлежит метод, но пока подробно не прорабатывал этот вопрос. Хочется, что бы по итогу этого шага утилита генерировала шаблоны, в которые останется только внести ожидаемые и тестовые значения и немного поправить сценарий, так как примитивная генерация сценарий + assert.Equal() уже должна присутствовать на данной стадии
Данный шаблон регулярно запускается с большим количеством тестов. стейдж проходит не сильно медленнее тестов написаных без шаблона, так как хорошо написанные тесты предполагают всё те же этапы.
Goland -> generate -> test for function дает то же самое. А статья зачем?
Привет! Спасибо за уделенное время)
Посмотрел на сгенерированный код goland и сравнил его со своим, мнение сугубо личное и я готов его пересмотреть, если я объективно не прав:
Плюсы кодгена. Отмечу простоту, эти тесты пря идеально подойдут для элементарных тестов, возможно именно такой простоты я добивался при продумывании своего шаблона. Нельзя забывать что этот подход ясно показывает, какие данные входят в функцию и что ожидается на выходе.
Минусы кодгена. Как, мне кажется, сразу заметно, что сгенерированная часть не такая гибкая. Её менее удобно использовать для сложных сценариев тестирования, где нужно проверять много аспектов работы функции.
Преимущества предложенного мной шаблона. Можно легко добавлять новые шаги в тест, такие как подготовка данных или дополнительные проверки. Как мне кажется, модульность и разделение ответственности компонентов позволяет легко модифицировать или переиспользовать код.
Минусы предложенного мной шаблона. Сейчас стреляю себе в ногу, но не могу быть не объективным. Очевидно, что мой паттерн может оказаться более сложный для понимания и настройки по сравнению с кодген шаблоном, который предоставляет нам goland, а так же он может быть избыточным при тестировании простых функций.
Как итог могу сказать, мне кажется, что предложенный шаблон лучше работает со сложными сценариями и лучше масштабируется под сложные проверки. Конечно, можно сделать проще, можно кодгенить, а мне хотелось предложить нечто читаемое и самое главное, я хотел это нечто сделать читаемым после масштабирования. Ну и по итогу мы собрали паттерн в универсальную тест/бенчмарк функцию.
Если все разбивать по функциям грамотно, то преимущества твоего подхода теряются. Не надо себе усложнять жизнь:)
Хорошая идея с testData и expectedData , возьму к себе в проект)
Привет! Спасибо за обратную связь)
Уточни пожалуйста, ты имеешь ввиду, что хорошая практика разбивать тесты и бенчмарки или что-то другое и почему преимущества теряются? Я с радостью подумаю как это пофиксить)
Отвечу немного наперед. Если вопрос касается того, что я разделяю ответственность внутри тестовой функции, но объединяю тесты и бенчмарки в одну функцию, то отвечу так. Разделять ответственность внутри теста это вклад в повышение стабильности тестов, что бы при добавлении новых кейсов не было коллизий и данные не могли пересечься между тестами. Объединение тестов и бенчмарков даже потенциально было спорным решением, но в тоже время это было вызовом и именно этот подход я хотел бы использовать при разработке генератора, так как я думаю, что сюда очень хорошо ляжет шаблон для кодогенерации.
Расскажи пожалуйста подробно, что тебя смущает, это очень важно для меня)
Спасибо, интересная статья! Подскажите, как при использовании данного шаблона работать с моками?
Привет! Рад, что тебе понравилось)
Использование моков подходит под описание "тесты со сценарием", так что я предлагаю использовать функции performAction и verifyResult в первой сделай мок и выполни запрос, а во второй проверь результат, в целом мок не нечто сложное и тестирование с ними практически ничем не отличается от других тестовых кейсов
Шаблон unit-тестов на Go