@Sebastian Спасибо за предложение. Это дает мне некоторые идеи для работы.
тоящее время я пытаюсь написать некоторые модульные тесты для SQL-кода SQL Server, используяtSQLt.
После прочтения документов выясняется, что не поддерживается возможность вызова тестового примера с параметрами вместо записи отдельных тестовых случаев для каждой комбинации параметров.(Ради этого вопроса, пожалуйста, отложите в сторону, считаете ли вы хорошей идеей передать параметры в тестовый пример вместо написания отдельного для каждой комбинации параметров)
Например, вNUnit Вы можете сделать что-то следующим образом, используяПрецедент атрибут:
[TestCase("", -1, false)]
[TestCase("ACT ", 1, true)]
[TestCase("ACT", 1, true)]
[TestCase("aCT", 1, true)]
[TestCase("AUSTRALIAN CAPITAL TERRITORY", 1, true)]
[Test]
public void DetermineStateIdFromText(string aStateText, long aExpectedStateId, bool aExpectedFound)
{
//Arrange
WzDetermineStateIdFromTextInput input = new WzDetermineStateIdFromTextInput
{
StateText = aStateText
};
//Act
WzDetermineStateIdFromTextOutput output = _WzLocationMappingService.DetermineStateIdFromText(input);
//Assert
output.ResultSuccess.ShouldBeTrue();
output.Found.ShouldBe(aExpectedFound);
if (output.Found)
{
output.StateId.ShouldBe(aExpectedStateId);
}
}
(Внутренние части метода теста не имеют значения и включены только для полноты. Вызов mustBe ()Shouldly на случай, если вам интересно, где находятся Asserts.)
Кто-нибудь получил какие-либо решения для обеспечения поддержки стиля TestCase в tSQLt?
Ответы на вопрос(1)
которые не являются тестовыми примерами в тестовых классах. Поэтому для достижения того, что вы ищете, я обычно создаю хранимую процедуру, которая принимает параметры и обрабатывает всю логику тестирования. Затем я пишу кучу однострочных тестовых процедур, которые вызывают другую процедуру, передавая соответствующие параметры. Для этого есть несколько примеров в тестовых примерах для самого tSQLt.
Этот подход имеет очень мало недостатков по сравнению с действительно параметризованными тестами, но имеет одно большое преимущество: вы можете дать каждому случаю действительно значимое имя, которое значительно упростит поиск проблем. (Истинные параметризованные тесты находятся в отставании, но они не имеют наивысшего приоритета, поэтому им может потребоваться некоторое время.)
В качестве примечания я настоятельно рекомендую не создавать автогенерационные тесты или даже параметры для тестов, поскольку это обычно приводит к более высоким затратам на техническое обслуживание. Поскольку целью тестирования является снижение затрат на поддержание вашей кодовой базы, это контрпродуктивно. По этой самой причине я видел, что многие проекты по внедрению модульного тестирования провалились.