Ответ 1
В целом...
Если ваша основная цель - проверить работу CRUD базы данных, я бы пошел как минимум на один уровень вниз и написал какие-то интеграционные тесты, которые не используют графический интерфейс для тестирования. Тесты становятся намного более сосредоточенными на действительных операциях CRUD, если вы выберете GUI.
Как работать с базой данных...
Независимо от того, идет ли речь о тестах Selenium или интеграции, неплохо, что тесты не зависят друг от друга. Это означает настройку базы данных перед каждым тестом и/или срывание их до состояния чистой/известной после теста. Поддержание тестов, написанных таким образом, намного проще. Например, вы можете запустить один тест самостоятельно.
Для наших тестов интеграции и приемочного тестирования мы используем dbunit для достижения этого. Легкая настройка и разрывание БД - это не новость, должно быть что-то доступное для вашего стека технологий. (Вы не упомянули технологии, которые используете)
Как классифицировать тесты...
Для операций CRUD я бы удостоверился, что проверю только одну вещь и одну вещь. Например, у меня есть таблица Employee. У вас может быть набор тестов, который проверяет все, что имеет отношение к Работнику, но один тест должен проверять только одно. "Сохранить сотрудника успешно" должен быть другим тестовым примером из "Попытка сохранить сотрудника, который уже существует" или "Удалить сотрудника".
EDIT: (ответьте на комментарий)
Мы в основном убиваем базу данных и создаем ее с нуля в начале тестирования. (Не уверен, насколько важна эта часть, но это гарантирует, что наш db соответствует тому, что ожидает код. Мы используем hibernate...)
Затем для каждого теста у нас есть разные наборы данных для вставки. Так что еще раз скажем, что мы тестируем Employee. Если я хочу протестировать удаление сотрудника, я бы ввел набор данных, содержащий самый маленький объем информации в базе данных, чтобы это произошло. Меньшие наборы данных легче поддерживать. Если вы используете один и тот же набор данных для всех своих тестов, будет очень сложно изменить код и изменить или добавить новые тесты.
Мы используем один и тот же набор данных для вещей, которые, как представляется, требуют одинаковой информации. Например, вы хотите протестировать "Попытка сохранить Employee to database" и "Delete Employee". Вы можете повторно использовать один набор данных для этого.
Мне было интересно, строят ли срывание БД для каждого теста было бы дорогостоящим временем и вычислениями мудрым?
Я бы не стал слишком беспокоиться об этом. Да, это может добавить, скажем, 3-4 секунды к каждому тесту, но на большой картине это действительно важно? Более важно, чтобы у вас были тесты, предназначенные для обслуживания, потому что ваше время в качестве разработчика намного ценнее, чем эти тесты, занимающие 5 минут, вместо 3 минут.