Как мне структурировать запросы к базе данных для простого тестирования? - PullRequest
1 голос
/ 15 февраля 2012

Я попробовал T (B) DD Kool-Aid, и я твердо убежден в его достоинствах, особенно в том, чтобы дать мне уверенность в том, что мой код правильный *

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

Function GetSomething(ByVal someData as DataType) as ResultType
    Connect to database
    create command/transaction
    initialise result variables
    Try
        lines and lines of SQL
        add parameters
        perform query
        While reader.read()
           read data into result variables
        End While
    Catch ex as DB2Exception 'Since we use db2, of course
        Do stuff
    Finally
        Clean up database variables
    End Try
    return results
End Function

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

Есть ли какие-либо статьи или вопросы с примерами того, что «правильный» метод для тестированияэтот слой?

Мы используем здесь VB и C #, но я думаю, что концепция довольно независима от языка, и у меня нет проблем с чтением более распространенных языков программирования.

* По крайней мере, так же правильно, как мои тесты;)

Редактировать:

Чтобы уточнить, я ищу , как структурировать мой код для тестирования, например, я не хочу код, которыйвыглядит так:

Property Testing as Boolean
Public Sub SomeInsertOrUpdateStatement(ByVal param as DataType)
    OpenConnection()
    Try
        If Testing Then
            ' Do one thing
        Else
            ' Do another thing
        End If
     Finally
        CloseConnection()
     End Try
End Sub

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

1 Ответ

0 голосов
/ 15 февраля 2012

Я бы сказал, интеграционные тесты, если это граница между вашим приложением и БД.

Должны быть роль / интерфейс (CustomerRepository) и реализация (SqlCustomerRepository).

  • Юнит-тесты: для тестирования остальной части приложения используется фальшивка / макет, основанная на интерфейсе CustomerRepository. Роль абстрагирует приложение от технологии, используемой для реализации хранилища
  • Интеграционные тесты: однако код, который вы разместили выше, выглядит так, как будто он принадлежит SqlCustomerRepository. Единственный способ проверить это - вызвать методы интерфейса и посмотреть, работает ли он с реальной базой данных Sql. Никаких насмешек или фальсификаций здесь ... эти тесты будут медленными (вы можете пометить его категорией, чтобы запускать их реже), но они проверяют, удовлетворяет ли SqlCustomerRepository контракт CustomerRepository.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...