"В три раза" против "найти подходящие из имеющихся, сделать им update под конкретный кейс, проверить, сделать update под следующий и так дальше". Об этом сказано в Результатах внедрения.
Если уже есть набор готовых insert-ов под нужные случаи, то переписывать их через цикл смысла немного, конечно. Разве что, при большом количестве полей, insert-ы, скорее всего, получатся длинными и придётся горизонтальным скроллом махать, что утомляет. Или, при большом количестве записей, лучше скрипт с циклом на один монитор, чем insert-ов на несколько...
Текст с картинкой лучше, чем без неё. Приятная картинка лучше, чем любая другая. Интересный женский силуэт, даже с ушами, скрасит любое окружение. То, что это из La2, поймут лишь побывавшие там. Они вспомнят что-то приятное, улыбнутся - уже хорошо! :) Остальные такого бонуса не получат, но увидят хорошую картинку, где герои смотрят не просто куда-то в даль, а на скрипт из статьи и решат: присоединиться к ним, или скроллить дальше. Как-то так :)
Данные генерятся быстро, если их не очень много, и коллегам это вряд ли помешает. Но, вероятность есть, да. Зависит от условий разработки.
С id надо очень аккуратно и внимательно, отталкиваясь от настроек базы/таблицы, разумеется.
По количеству тестовых записей
"Обычно" у всех свои) Для функционального тестирования алгоритмов, с которыми мне приходилось сталкиваться, было достаточно нескольких десятков, реже сотен, записей в 3-5 таблицах.
Бывало, генерил и тысячами но редко. В этих случаях, обработка нагенерённого занимала заметно больше времени, чем их создание. Там, где всё начинается от десятков тысяч, вероятно, надо что-то куда более хитрое, что-то из арсенала нагрузчиков.
По удалению
Конечно, за собой надо убирать) Если проверка автоматизирована, то в конце должен выполняться скрипт с удалением, даже если сама проверка завалилась. Об этом упомянуто. Если проверка ручная, то последним шагом должно быть удаление нагенерённого, как и в любом другом случае добавления данных или изменения настроек для конкретного тест кейса.
Удаление в начале скрипта как раз на тот случай, если в прошлый раз что-то пошло не так. Главная цель - обеспечить условия выполнения insert-ов и удалить данные, которые могут повлиять на обработку нагенерённого.
"В три раза" против "найти подходящие из имеющихся, сделать им update под конкретный кейс, проверить, сделать update под следующий и так дальше". Об этом сказано в Результатах внедрения.
Если уже есть набор готовых insert-ов под нужные случаи, то переписывать их через цикл смысла немного, конечно. Разве что, при большом количестве полей, insert-ы, скорее всего, получатся длинными и придётся горизонтальным скроллом махать, что утомляет. Или, при большом количестве записей, лучше скрипт с циклом на один монитор, чем insert-ов на несколько...
Текст с картинкой лучше, чем без неё. Приятная картинка лучше, чем любая другая. Интересный женский силуэт, даже с ушами, скрасит любое окружение. То, что это из La2, поймут лишь побывавшие там. Они вспомнят что-то приятное, улыбнутся - уже хорошо! :) Остальные такого бонуса не получат, но увидят хорошую картинку, где герои смотрят не просто куда-то в даль, а на скрипт из статьи и решат: присоединиться к ним, или скроллить дальше. Как-то так :)
По доступу к базе и id
Данные генерятся быстро, если их не очень много, и коллегам это вряд ли помешает. Но, вероятность есть, да. Зависит от условий разработки.
С id надо очень аккуратно и внимательно, отталкиваясь от настроек базы/таблицы, разумеется.
По количеству тестовых записей
"Обычно" у всех свои) Для функционального тестирования алгоритмов, с которыми мне приходилось сталкиваться, было достаточно нескольких десятков, реже сотен, записей в 3-5 таблицах.
Бывало, генерил и тысячами но редко. В этих случаях, обработка нагенерённого занимала заметно больше времени, чем их создание. Там, где всё начинается от десятков тысяч, вероятно, надо что-то куда более хитрое, что-то из арсенала нагрузчиков.
По удалению
Конечно, за собой надо убирать) Если проверка автоматизирована, то в конце должен выполняться скрипт с удалением, даже если сама проверка завалилась. Об этом упомянуто. Если проверка ручная, то последним шагом должно быть удаление нагенерённого, как и в любом другом случае добавления данных или изменения настроек для конкретного тест кейса.
Удаление в начале скрипта как раз на тот случай, если в прошлый раз что-то пошло не так. Главная цель - обеспечить условия выполнения insert-ов и удалить данные, которые могут повлиять на обработку нагенерённого.