Написание тестового примера

Question

Как написать контрольные примеры для запросов SQl?

• существует ли какая-либо процедура или формат для подражания?
• например, у меня запрос на вставку со сложными объединениями, и как разработать тестовый пример для этого.

Answer 1

Это кажется интересным, так как я не уверен в ваших требованиях.

ИМХО, тестовые примеры хороши для написания для функционального или системного тестирования (или тестирования черного ящика в целом).Тестовые случаи - это перевод спецификаций требований или историй пользователя.В случае тестирования запроса, я не уверен, нужно ли нам писать тестовый пример (это становится тестированием белого ящика).В таком случае лучше написать для них модульные тесты, чем создавать тестовые случаи вручную.Может быть, я что-то здесь упускаю.

Однако, учитывая, что у вас другое мнение, о котором я не знаю, моя идея заключается в следующем.

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

РЕДАКТИРОВАТЬ: Если вы хотите написать модульные тесты, пожалуйста, проверьте DBUnit , который поможет вам

1. Создать соединение с БД легко из модульного теста
2. Чтобы создать пример данных в XML и загрузить их в свои таблицы
3. Проверка данных после выполнения некоторых транзакций базы данных или подтверждения данных за один шаг

Например, рассмотрите следующеесценарий.У вас есть БД школы.Теперь вы написали сложный запрос, который извлекает список студентов.Вы должны проверить, работает ли этот запрос нормально.Затем вы можете создать блок модульного теста, используя DBUnit или Unitils , который будет динамически создавать вашу таблицу и загружать ваши образцы данных, выполнять ваш запрос и затем сравнивать набор результатов с данными, которые вы ожидаете.Все в одном автоматизированном модульном тесте.

Это пример из Unitils,

открытый класс UserDAOTest extends UnitilsJUnit4 {

@Test
@DataSet("UserDAOTest.testFindByMinimalAge.xml")
public void testFindByMinimalAge() {
    List<User> result = userDao.findByMinimalAge(18);        
    assertPropertyLenientEquals("firstName", Arrays.asList("jack"), result);
}

}

Доэтот тест выполняется, образцы данных из этого "UserDAOTest.testFindByMinimalAge.xml" будут загружены в таблицу, которую вы конфигурируете, и позже будет выполнен тест и запрос внутри него.Аналогичным образом, если вы используете аннотацию @ExpectedDataSet вместо @DataSet, данные в этом xml будут использоваться для сравнения набора результатов после выполнения теста.

В случае использования JPA-Hibernate, вытакже можно выполнить эффективное модульное тестирование с использованием БД в памяти.

Надеюсь, это поможет.

Answer 2

Различные базы данных имеют разные тестовые наборы. MySQL / Percona Server / MariaDB все используют варианты mysql-test-run:

http://dev.mysql.com/doc/mysqltest/2.0/en/mysql-test-run-pl.html

Морось также использует вариант этого: http://docs.drizzle.org/testing/test-run.html

Это простые тесты на основе различий. Вы пишете, какие запросы ожидаете увидеть, побуждает бегун выполнять их, а затем проверять результаты. Вы сохраняете ожидаемый вывод в файле .result и гарантируете, что последующие запуски демонстрируют то же поведение / результаты.

Существуют и другие инструменты, которые вы можете использовать, например генератор случайных запросов:

http://forge.mysql.com/wiki/RandomQueryGenerator

Преимущество этого инструмента в том, что он может работать как с системами Postgres и Javadb, так и с системами на основе MySQL.

Он также позволяет выполнять одинаковые запросы к двум серверам. Это позволяет тестировать сложные запросы, выполняя их как на тестируемом сервере, так и на доверенной реализации (например, сравнивая результаты Drizzle и стоковые MySQL для одного и того же запроса) с проверкой результатов запроса вручную.