AV
ну ресурсы гораздо экономнее регулярно освобождать раз в час/день/месяц - чем после каждого теста.
Size: a a a
2019 December 30
LY
Это да, но лучше использовать такой скрипт в качеств подстраховки, чем полность полагаться на него.
AV
Несмотря на то что данные уникальные, упавший тест может занять ресурсы стенда например. И один из последующих тестов упадёт из-за того что ресурсов не хватило.
что может открыть неизвестную проблему нехватки ресурсов. Настоящие пользователи в продакшн редко подчищают за собой данные.
LR
что может открыть неизвестную проблему нехватки ресурсов. Настоящие пользователи в продакшн редко подчищают за собой данные.
Ну ресурсы то у Вас вряд ли такие же как на продакшине.
AK
что может открыть неизвестную проблему нехватки ресурсов. Настоящие пользователи в продакшн редко подчищают за собой данные.
Значит надо написать тест на проверку нехватки ресурсов
AV
вряд ли, тем не менее - для лучшей стабильности тестов лучше никогда ничего нигде не менять, но тесты мы пишем как раз для того, чтобы они находили (реальные) проблемы - а не были всегда вечнозелёными.
AV
Значит надо написать тест на проверку нехватки ресурсов
ну вот - профит!
MA
Скрипт на проверку скрипта, проверяющего нехватку ресурсов
AV
ну так, чисто на практике - уже не раз находили проблемы (реальные) в коде, благодаря тому, что данные не подчищали.
B
После завершения теста (сьюта), хорошо приводить SUT в состояние перед тестом (сьютом), вне зависимости от результата теста(сьюта).
Чтобы не мешать работе последующих тестов или тестировщиков.
Чтобы не мешать работе последующих тестов или тестировщиков.
Лучше наоборот, перед тестами готовить окружение тестовое.
AV
Лучше наоборот, перед тестами готовить окружение тестовое.
я к тому выводу прихожу
LY
Лучше наоборот, перед тестами готовить окружение тестовое.
Это тоже нужно делать, но подчищать - после. Тесты могут не идти по порядку, да и писать логику которая будет смотреть что упало и что почистить перед тестом - это странно. Другое дело если к примеру до тестов разворачивается дамп базы или создается стенд. Тогда имеет смысл оставить только поготовку без teardown.
B
Это тоже нужно делать, но подчищать - после. Тесты могут не идти по порядку, да и писать логику которая будет смотреть что упало и что почистить перед тестом - это странно. Другое дело если к примеру до тестов разворачивается дамп базы или создается стенд. Тогда имеет смысл оставить только поготовку без teardown.
Так и делаем, поднимается свежий дамп базы, делаются для отдельных тестов при необходимости изменения в бд. В конце ничего не чистим)
AV
Так и делаем, поднимается свежий дамп базы, делаются для отдельных тестов при необходимости изменения в бд. В конце ничего не чистим)
еретики
B
еретики
Мы просто ленивые)
AV
протестанты
B
протестанты
Ещё добавлю,у нас даже стенды умирают после тестов). Удаляются наглухо )
B
Все тлен
AR
ну так, чисто на практике - уже не раз находили проблемы (реальные) в коде, благодаря тому, что данные не подчищали.
+1
AR
Так и делаем, поднимается свежий дамп базы, делаются для отдельных тестов при необходимости изменения в бд. В конце ничего не чистим)
А как у вас стенд устроен?