Будет ли модульный тест добавлять какое-либо значение к этому примеру поставщика DAL помимо интеграционного теста?

Question

public List<int> GetPortfolioList()
{
    using (var connection = new SqlConnection("<connectionString>"))
    using (var command = new SqlCommand("SELECT * FROM Portfolio", connection))
    {
        connection.Open();
        var portfolioTable = SqlHelper.GetDataTable(command);
        var portfolios = from DataRow row
                            in portfolioTable.Rows
                            select int.Parse(row["Portfolio"].ToString());

        return portfolios.ToList();
    }
}

Используйте этот метод в поставщике SQL DAL для получения списка портфелей, как следует из названия (и кода). Поскольку таблица базы данных для интеграционного тестирования содержит довольно статический набор данных, мы можем утверждать, вопреки нескольким ожиданиям. например Список портфелей будет: - не быть пустым - содержат определенные известные значения - не содержат дубликатов

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

Answer 1

Я возьму противоположное мнение, потому что я только что закончил писать поддельные БД (используя в списках памяти), чтобы сделать linq to sql (или linq to что угодно) тестируемым модулем.

Это один вопрос, который я использовал, чтобы выбрать подходящий способ подделать / смоделировать базу данных. (хотя при чтении вашего кода встроенный «SELECT * FROM» означает, что вы полагаетесь на SQL больше, чем на linq, что усложнит процесс преобразования вашего кода в такие вещи, которые имеет для выполнения SQL Server и вещи, с которыми может справиться linq.

Как люди тестируют код, использующий Linq to SQL

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

Например, как ваш код реагирует, если row ["Portfolio"]. ToString () имеет значение null, как реагирует код, если он не возвращает никаких строк или возвращает 2?

И даже если вы выполняете только интеграционные тесты, nunit не является плохим способом интеграционных тестов, просто будьте осторожны, чтобы не называть их модульными тестами, иначе бы пурист не расстроился из-за этого.

Answer 2

Метод использует Linq для проецирования некоторых значений из БД в список целых чисел - вы можете проверить, правильно ли он это делает.

Я бы разделил код на две части - извлечение данных и проекция (запрос Linq) - тогда вы могли бы протестировать запрос linq с помощью макета data , без необходимости имитировать базу данных.

Я бы также сказал, что в модульном тестировании кода доступа к данным мало значения.

Answer 3

Как пурист-тестировщик, я считаю, что не могу «модульно протестировать» DAL, потому что не могу сделать это изолированно. Это означает, что часть моего кода, взаимодействующего с базой данных, проходит без модульного тестирования. Код выше выглядит хорошо; просто убедитесь, что он существует как часть более крупного контракта, который вы можете проверить в других объектах.

Тем не менее, я выполняю интеграционное тестирование, собирая базу данных, заполняя ее и гарантируя, что мой DAL работает.

Answer 4

Я был бы согласен с вами, единственное значение здесь - интеграционное тестирование, на самом деле нет ничего для модульного тестирования, не будучи педантичным.

Код модульного теста для всех вызывающих этот метод должен издеваться над этим методом,конечно.

e: Исключительные случаи, о которых упоминал МэтьюМартин, были бы единственными вещами, которые я бы посчитал достойными модульного тестирования в этом сценарии.