Изоляция логики возможно и внутри монолита (например DDD). Я думаю не всегда есть смысл разбивать на микросервисы, особенно до того как будет сделано четкое разделение логики внутри монолита. У меня еще такой вопрос возник - а локально разработчик прогоняет тесты по этой же схеме?
Именно это не понятно, почему нельзя сгенировать моки этих сущностей? т.е. как обычно и должны работать unit тесты - тестировать только конкретный функционал и не тестировать задачи, которые не являются ответственностью данного сервиса.
Прочитал статью, и у меня сложилось впечатление, что на ключевые вопросы автор так и не ответил. Например:
Почему именно тестовые данные вызывают такие проблемы с производительностью?
Почему нельзя генерировать тестовые данные на уровне session и удалять их в конце, вместо создания отдельных наборов для каждого файла или сьюта?
В чем смысл ночной генерации отдельных тестовых данных вместо их динамического создания перед запуском тестов?
Из-за чего тесты работают так медленно — в статье это практически не раскрыто?
Создается впечатление, что основное ускорение достигнуто за счет распараллеливания, тогда как фундаментальные причины медленной работы тестов остаются неясными. Было бы полезно увидеть более глубокий анализ первопричин и архитектурных ограничений, влияющих на скорость тестов.
Приведу пример из собственного опыта: я ускорял выполнение тестов в несколько раз просто за счет изменения scope у fixture для создания движка базы с function на session. В статье такие нюансы не рассматриваются, хотя во многих проектах именно неверный scope у фикстур является одной из ключевых причин медленного выполнения тестов.
Статья довольно слабая, по большей части в качестве примера видимо взята Django ORM, которая действительно много чего автоматизирует, если взять SqlAchemy, он позволяет писать практически любые запросы без ограничений и без знания SQL им пользоваться нормально по сути невозможно. Поэтому я бы сказал так - на ORM сложные запросы сложнее писать, но проще читать и поддерживать. С Raw-запросами ровно наоборот, вот собственно и весь спор.
Сам range не является генератором, он реализует протокол последовательности, тогда как генераторы реализуют протокола Итератора. По этому нельзя вызвать next(range(100)) и именно поэтому к одному и тому же range можно обращаться многокртано.
Хранить в JWT токене пароль - не безопасно и абсолютно не нужно, достаточно проверять один раз при создании токена. Даже для примера так делать не нужно.
Рандомная генерация данных позволяет отловить больше потенциальных ошибок, чем когда эти данные создаются вручную, вручную данные получаются чаще ближе к идеальным условиям и тесты с ними c большей вероятностью будут пропускать уязвимости.
Изоляция логики возможно и внутри монолита (например DDD). Я думаю не всегда есть смысл разбивать на микросервисы, особенно до того как будет сделано четкое разделение логики внутри монолита. У меня еще такой вопрос возник - а локально разработчик прогоняет тесты по этой же схеме?
Именно это не понятно, почему нельзя сгенировать моки этих сущностей? т.е. как обычно и должны работать unit тесты - тестировать только конкретный функционал и не тестировать задачи, которые не являются ответственностью данного сервиса.
А что уже пробовали? RAG на базе векторной базы?
Прочитал статью, и у меня сложилось впечатление, что на ключевые вопросы автор так и не ответил.
Например:
Почему именно тестовые данные вызывают такие проблемы с производительностью?
Почему нельзя генерировать тестовые данные на уровне
sessionи удалять их в конце, вместо создания отдельных наборов для каждого файла или сьюта?В чем смысл ночной генерации отдельных тестовых данных вместо их динамического создания перед запуском тестов?
Из-за чего тесты работают так медленно — в статье это практически не раскрыто?
Создается впечатление, что основное ускорение достигнуто за счет распараллеливания, тогда как фундаментальные причины медленной работы тестов остаются неясными. Было бы полезно увидеть более глубокий анализ первопричин и архитектурных ограничений, влияющих на скорость тестов.
Приведу пример из собственного опыта: я ускорял выполнение тестов в несколько раз просто за счет изменения
scopeу fixture для создания движка базы сfunctionнаsession. В статье такие нюансы не рассматриваются, хотя во многих проектах именно неверныйscopeу фикстур является одной из ключевых причин медленного выполнения тестов.Статья довольно слабая, по большей части в качестве примера видимо взята Django ORM, которая действительно много чего автоматизирует, если взять SqlAchemy, он позволяет писать практически любые запросы без ограничений и без знания SQL им пользоваться нормально по сути невозможно. Поэтому я бы сказал так - на ORM сложные запросы сложнее писать, но проще читать и поддерживать. С Raw-запросами ровно наоборот, вот собственно и весь спор.
Сам range не является генератором, он реализует протокол последовательности, тогда как генераторы реализуют протокола Итератора. По этому нельзя вызвать next(range(100)) и именно поэтому к одному и тому же range можно обращаться многокртано.
Хорошая статья, спасибо
Хранить в JWT токене пароль - не безопасно и абсолютно не нужно, достаточно проверять один раз при создании токена. Даже для примера так делать не нужно.
Да, такие ситуации случались, но я, увы, не веду по ним записи. Чаще всего это приводит к flaky(моргающим) тестам.
Рандомная генерация данных позволяет отловить больше потенциальных ошибок, чем когда эти данные создаются вручную, вручную данные получаются чаще ближе к идеальным условиям и тесты с ними c большей вероятностью будут пропускать уязвимости.