Как проверить метод, который имеет запросы к базе данных для обновления данных?

Question

У меня есть метод, подобный следующему:

public void ImportDataCommand()
{
    // some data validation logic here

    if (some_criteria_is_true)
    {
        // Call to a method which uses sql queries to update some records
        UpdateRecords();
    }
    else
    {
        // Call to a method which uses sql queries to delete some records
        DeleteRecords();
    }
}

• Как я могу выполнить модульные методы тестирования UpdateRecords() и DeleteRecords()?(если возможно)
• Является ли текущая модель, которая у меня есть, запахом?
• Есть ли лучший способ обработки, когда у вас есть какая-то логика обновления данных, которая зависит от какой-то логики проверки данных и некоторой условной логики?

Любая помощь в этом отношении оченьоценили.Пожалуйста, дайте мне знать, если вам нужна дополнительная информация или что-то неясно.

Обновление:

Меня не интересует насмешка над источником данных здесь.Я хочу убедиться, что мои sql-запросы верны и делают правильные обновления.Извините за путаницу, если вы подумали, что я хотел протестировать свою логику проверки, а не логику обновления данных (sql).

У меня есть опыт работы с фреймворками и я успешно использовал их для написания модульных тестов.для моей обычной логики приложения.

Answer 1

Ваша проблема начинается с фразы ', а также' .

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

class Bar {
private DataAccessService service

public void Foo()
{
    // some data validation logic here

    if (some_criteria_is_true)
    {
        // Call to a method which uses sql queries to update some records
        service.updateBarRecords();
    }
    else
    {
        // Call to a method which uses sql queries to delete some records
        service.deleteBarRecords();
    }
}

}

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

Answer 2

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

Итак, в вашем случае кода вы должны написать тестовые случаи для Foo (), UpdateBarRecords () и DeleteBarRecords () по отдельности.

Игнорировать все вызовы методов (модульное тестирование)и сконцентрируйтесь на основном логическом коде, который вы написали в этом методе, который вы концентрируетесь для модульного тестирования.

Answer 3

ИМХО, вы должны решить эту проблему в своем коде:

1. Foo не проверяется модулем, потому что он ничего не возвращает
2. Вы связываете доступ к данным с вашимлогика приложения, которая делает разные слои слишком связанными, чтобы фактически единица проверять их
3. Вероятно, метод, в котором вы вызываете update и delete в зависимости от определенного условия, является запахом ... mustn 'не лучше ли иметь два разных поведения?

Поскольку наименование Foo самоочевидно, больше ничего нет, но если бы вы могли детализировать контекст метода, мы могли бы добавить больше замечаний.

Answer 4

Это зависит от всей архитектуры вашего приложения и инфраструктуры ИТ / БД компании, а также от политик данных, которые вы можете применять для администраторов баз данных в средних или крупных компаниях.

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

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