Size: a a a

2019 April 12

ДБ

Дмитрий Бабенко... in testspro1c
Проще создать для теста окружение, чем чистить после каждого. Ну и в некоторых случаях тест можно поместить в транзакцию, тогда и чистить после него ничего не надо
источник

LP

Leonid Pautov in testspro1c
Можно по разному делать. Если коротко:
1. Мы при тестировании ERP, БСП и т.д. загружаем базу из эталона после каждого сценария. Это даёт больше нагрузки на инфраструктуру. Зато сценарии создавать быстрее.
2. Кто-то пытается сценарий написать так, чтобы он сам подготоваливал окружение для своей работы. Это меньше грузит инфраструктуру, но такие сценарии писать сложнее.
Если добиться изолированности сценария просто - то лучше к этому стремиться конечно.
источник

АА

Александр Алехин... in testspro1c
Alexander Tsukanov
Тесты могут быть зависимыми, могу быть независимыми, могут быть какими угодно.
Это все идеологическая чепуха. Нужно делать так, как удобно и эффективно, имхо.
👍
источник

i

i_solaris in testspro1c
Всем спасибо. Транзакции нам не подошли. Загружать эталон пока видимо проще всего получится.
источник

i

i_solaris in testspro1c
Хотя сейчас даже пустые базы очень даже немаленькие.
источник

i

i_solaris in testspro1c
Поделитесь еще, пожалуйста, мыслями, по какому принципу разделять данные эталонной базы, а что воспроизводить в контексте к тесту.
источник

LP

Leonid Pautov in testspro1c
Если база файловая - копируйте Файлы между каталогами. Это быстрее, чем dt загружать.
источник

i

i_solaris in testspro1c
Ага, так и делаю.
источник

i

i_solaris in testspro1c
Т.е. в моем примере. Если делать на пустой базе и нет узла плана обмена, то будет ошибка любого другого сценария. Но если брать эталонную базу сразу с узлом, то ошибок не будет.
источник

AA

Artur Ayukhanov in testspro1c
Alexander Tsukanov
Тесты могут быть зависимыми, могу быть независимыми, могут быть какими угодно.
Это все идеологическая чепуха. Нужно делать так, как удобно и эффективно, имхо.
А если не приклеивать ярлыки заранее про "идеологическую чепуху", а попытаться понять, как и почему рождаются такие требования, можно больше пользы получить и продуманнее к выбору вариантов реализации подходить ;)
источник

AT

Alexander Tsukanov in testspro1c
А если все таки попытаться понять почему это чепуха? ;)
ps Троллирую, да. Надеюсь намек понят
источник

i

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

AA

Artur Ayukhanov in testspro1c
i_solaris
Т.е. в моем примере. Если делать на пустой базе и нет узла плана обмена, то будет ошибка любого другого сценария. Но если брать эталонную базу сразу с узлом, то ошибок не будет.
Эталонная база не гарантирует ничего. Она только упрощает создание данных.
И если не соблюдать неявные правила по запрету изменений существующих данных, то легко получить каскадные паления тестов;)
И даже если соблюдать, все равно можно получать.
Неявное - оно всегда больно
источник

AA

Artur Ayukhanov in testspro1c
Alexander Tsukanov
А если все таки попытаться понять почему это чепуха? ;)
ps Троллирую, да. Надеюсь намек понят
Мы с тобой еще в личке пообщаемся по этому и соседним поводам.возникла потребность
источник

i

i_solaris in testspro1c
Я пока тоже за явное. Но тогда контексты большие получаются :) и много другого проверяют. В связи какая практика сложилась - создавать данные кодом/загрузкой или имитацией действий пользователей?
источник

AA

Artur Ayukhanov in testspro1c
Дмитрий Бабенко
Проще создать для теста окружение, чем чистить после каждого. Ну и в некоторых случаях тест можно поместить в транзакцию, тогда и чистить после него ничего не надо
Вообще одна из аксиом тестирования - каждый тест или набор тест должен гарантировать, что он работает в правильном окружении, например, с правильными данными.
Достигается разными способами
источник

AT

Alexander Tsukanov in testspro1c
Artur Ayukhanov
Мы с тобой еще в личке пообщаемся по этому и соседним поводам.возникла потребность
Интрига! )
источник

A

Alexey Lab Sosnoviy in testspro1c
Alexander Tsukanov
Интрига! )
Звучит как угроза))
источник
2019 April 13

AA

Artur Ayukhanov in testspro1c
Никакой угрозы, просто пообщаться
источник

DR

Dmitry Reshitko in testspro1c
i_solaris
У меня общий вопрос, где я, видимо, запутался. Читал, что тесты должны быть независимыми, с другой стороны - очищать данные не нужно. Но в таком случае получается, что результат может зависеть от последовательности тестов. Пример. Есть 2 теста один проверяет обмен, второй проведение документа. Написано так, что при проведении документа выполняется регистрация на узле плана обмена. Получается что если я сперва прогоняю тест обмена, то в контексте будет создан узел ПО и тест проведения документа не упадет, но если последовательность поменять, то проведение падает. Это пример вроде доказывает, что тесты должны быть изолированными. Получается, что подчищать после каждого теста нужно обязательно? Или я где-то в корне не прав?
Возможно, вы читали мои статьи, я об этом писал, и там же приводил доводы в пользу такого подхода, если кому-то это кажется идеологической чушью, а значит утверждается что связность тестов равносильно несвязности, просьба подкреплять слова умозаключениями на практических примерах, с выдержкой мало-мальской критики. Но вернемся к вашему примеру. Если тесту проведения документа нужен узел, значит это его окружение, которое должно быть создано до проверки проведения самим тестом проведения. А тот факт, что у вас есть тест _проверки_ создания узла вовсе не означает, что будет 1) создан именно тот узел, который нужен проведению документа 2) Тест проверки создания узла может упасть по причинам совершенно не связанным с проверкой проведения, например вы добавите в него проверку видимости какого-то реквизита в каком-то особом случае создания, и это падение повлечет за собой падение проведения документа (которому с точки зрения проведения - вообще неважен этот особый случай создания). И теперь представьте, что у вас сам документ проверки поступления еще используется для другого теста, и вот все они дружно упадут. Проблема? Может скажете что и нет, но очень скоро вы можете начать испытывать страх перед очередным изменением теста, по приниче его связности.
источник