Здравствуйте.

Пишу сюда, потому что раздел "Тестирование", кажется, мёртв.
В общем, в нашей системе есть классы, которые генерируют SQL-код по неким переданным параметрам (в виде объектов).
Сейчас тесты выглядят как-то так:

string generatedSql = generator.BuildSelectStatement(queryOptions);
Assert.AreEqual(generatedSql, @"SELECT T.f1, T.f2 FROM table1 T WHERE T.f1=42"); // типа того, только намного длиннее

И тесты получаются очень хрупкие. Во-первых, мешается форматирование — пробельчики и тому подобное.Во-вторых, стоит добавить, например, в генерируемый код комментарий, и приходится добавлять его в тесты.

Какой есть "правильный" способ тестировать такое?

Здравствуйте, dmitry_npi, Вы писали:

_>

_>string generatedSql = generator.BuildSelectStatement(queryOptions);
_>Assert.AreEqual(generatedSql, @"SELECT T.f1, T.f2 FROM table1 T WHERE T.f1=42"); // типа того, только намного длиннее
_>

_>И тесты получаются очень хрупкие. Во-первых, мешается форматирование — пробельчики и тому подобное.Во-вторых, стоит добавить, например, в генерируемый код комментарий, и приходится добавлять его в тесты.

_>Какой есть "правильный" способ тестировать такое?

Можно выполнять запросы на тестовой БД и сравнивать результаты.
Можно парсить запросы/нормализовать и сравнивать уже после этого.

Здравствуйте, GarryIV, Вы писали:


GIV>Можно парсить запросы/нормализовать и сравнивать уже после этого.
Хотелось бы пойти по этому пути, но не хочется тестировать сам код тестирования . Знаете какую-нибудь библиотеку для этого (C#)?

Здравствуйте, dmitry_npi, Вы писали:

_>И тесты получаются очень хрупкие. Во-первых, мешается форматирование — пробельчики и тому подобное.Во-вторых, стоит добавить, например, в генерируемый код комментарий, и приходится добавлять его в тесты.

_>Какой есть "правильный" способ тестировать такое?

Как вариант:

Добавить промежуточный слой. BuildSelectStatement генерирует промежуточные объекты Select, From, Where.
Например, на основе queryOptions будет сформировано: Select('T.f1'), Select('T.f1'), From('table1', 'T'), Where('T.f1=42'), NestedQuery(), OrderBy(), etc
Тестировать количество получившихся промежуточных объектов.

Потом из этих промежуточных объектов формировать строку запроса.
Протестировать построение строки запроса из небольшого количества промежуточных объектов.

Ну и еще варианты (которые, скорее всего, "не варианты"):
— Оставить как есть. Но раз задали вопрос, то проблема назрела.
— Не тестировать получившийся запрос как строку. Тестировать отправляя запрос в БД с тестовыми данными. Для больших запросов — не реально, т.к. трудно готовить тестовые БД.

Здравствуйте, dmitry_npi, Вы писали:

GIV>>Можно парсить запросы/нормализовать и сравнивать уже после этого.
_>Хотелось бы пойти по этому пути, но не хочется тестировать сам код тестирования . Знаете какую-нибудь библиотеку для этого (C#)?

За C# не знаю (мы в Java парсили), гугл говорит что тоже есть либы.
Сильно зависит от диалекта, с DML все было относительно хорошо, проблемы были с DDL.

Здравствуйте, dmitry_npi, Вы писали:

_>Какой есть "правильный" способ тестировать такое?

Простейший метод, удаляющий лишние пробелы, табы, переводы строк, комментарии из сравниваемых строк.

Здравствуйте, dmitry_npi, Вы писали:

_>И тесты получаются очень хрупкие. Во-первых, мешается форматирование — пробельчики и тому подобное.Во-вторых, стоит добавить, например, в генерируемый код комментарий, и приходится добавлять его в тесты.
Ещё как вариант — тесты писать как whitebox и делать ассерты более слабыми в большинстве тестов, чтобы они тестировали только определённый аспект функциональности.
Т.е. например,

string generatedSql = generator.BuildSelectStatement(queryOptions.withF1(42));
Assert.ContainsSubstring(generatedSql, @"T.f1=42");

Ну и сделать пару сложных тестов, которые сравнивают строки целиком и только они будут хрупкими.

Здравствуйте, dmitry_npi, Вы писали:

_>Какой есть "правильный" способ тестировать такое?

Это зависит от определения "правильности". В чем смысл данного теста? Что он должен проверять? Что генератор сгенерировал "нечто" синтаксически правильное? Тогда проверить это можно, подключившись к БД и выполнив prepare.