@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.

Этот подход имеет очень мало недостатков по сравнению с действительно параметризованными тестами, но имеет одно большое преимущество: вы можете дать каждому случаю действительно значимое имя, которое значительно упростит поиск проблем. (Истинные параметризованные тесты находятся в отставании, но они не имеют наивысшего приоритета, поэтому им может потребоваться некоторое время.)

В качестве примечания я настоятельно рекомендую не создавать автогенерационные тесты или даже параметры для тестов, поскольку это обычно приводит к более высоким затратам на техническое обслуживание. Поскольку целью тестирования является снижение затрат на поддержание вашей кодовой базы, это контрпродуктивно. По этой самой причине я видел, что многие проекты по внедрению модульного тестирования провалились.

 TheEdge20 дек. 2017 г., 02:33
@Sebastian Спасибо за предложение. Это дает мне некоторые идеи для работы.

Ваш ответ на вопрос