Написание тестовых случаев

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

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

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

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

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

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

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

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

открытый класс UserDAOTest расширяет 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, вы также можете выполнить эффективное модульное тестирование с использованием базы данных в памяти.

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

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

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

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

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

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

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

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

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