[Bug]: При запуске теста не сбрасываются повторно используемые значения.

[EvgSychev]

🐞 Описание ошибки

При использовании кэширующих модулей закэшированные значения "просачиваются" в последующие тесты. Предлагаю при запуске тестов принудительно сбрасывать кэш.

Пример кода

No response

Текст ошибки (лог)

No response

Версия YaxUnit

23.8.0

Версия 1С:Предприятие

8.3.24.1758

Режим запуска 1С:Предприятие

Тонкий клиент. Управляемое приложение

Тип информационной базы

Файловая

Операционная система

Windows

[alkoleft]

Решить эту проблему можно двумя способами:

1. В обработчике "ПередКаждымТестов" добавить сброс кэша
2. Создать в тестах свой модуль и подписать его на события теста и там уже реализовать глобальный сброс кешей.
3. Поддержать функциональность в движке, но сделать ее опциональной (в рамках всех тестов/модулей/набор или конкретных тестов)
4. Поддержать функциональность в движке безусловно

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

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

Хочется понять, насколько это может быть больно и критично, я не сталкивался пока с подобными проблемами в тестах.

[EvgSychev]

Проблема была в тесте проверяющем загрузку сообщения интеграции.
Первый сценарий - пришёл ид, объекта нет в базе. Объект искался по ид методом кэширующего модуля.
Второй сценарий - пришёл ид, объект в базе есть. Объект создавался в тесте, но из-за того, что первый сценарий уже заполнил кэш тест не проходил.

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

[alkoleft]

Тут проблема связана с тем, что скорее всего использовалась реальная интеграция, с реальным, а не мокируемым сервисом интеграции. Что не есть хорошо для тестов.

Подобное может конечно возникнуть и в других ситуациях. Посмотрю как повлияет сброс повторного использования для каждого теста.

[EvgSychev]

Нет, тестировался метод в который загружался тестовый json.

[alkoleft]

Сброс повторно используемых добавил ~15 сек (20-25%) к общему времени выполнения тестов на тестах движка.
В процентах конечно существенно, но тут все мелкие тесты, так что думаю оправдано.