Интерактивные модули базы данных тестирования модулей

Question

У меня есть компонент взаимодействия с базой данных, который, среди прочего, является классом Writer и Reader. Класс writer имеет такие методы записи, как insertEntity (Entity) и updateEntity (Entity), в то время как Reader имеет такие методы, как getEntityById (EntityId).

Для реализации этого компонента я хотел бы использовать TDD, как я обычно делаю, хотя не знаю, как это можно сделать. Если я начну с реализации Writer, как я буду делать значимые утверждения, если у меня еще нет методов Reader. И даже если бы у меня были методы Reader, я бы предпочел не использовать их в тестах для Writer, хотя, возможно, это принятие желаемого за действительное.

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

Answer 1

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

Например, если я сделал метод getEntityById, я мог бы иметь класс, который будет использовать память в памяти (массив, хеш и т. Д.). Хотя мой производственный код будет использовать конкретный экземпляр. В псевдокоде:

 
class MemoryStore 
{ 
    getEntityById(id) 
    { 
     // Return hardcoded response or canned results 
    } 
} 

class DatabaseStore 
{ 
    getEntityById 
    { 
     // Go off to the real database and do reads. 
    } 
} 

Вы можете затем написать вам тесты, не забирая реальную базу данных. Помните, что если вы используете сторонний сервис, API, БД, файловую систему и т. Д., Вы не являетесь модульным тестированием.

Другое преимущество здесь в том, что вы можете иметь другого разработчика, работающего над кодом доступа к базе данных, в то время как вы работаете с остальной частью приложения. Все это зависит от «кодирования интерфейса».

Что делать, если вы хотите протестировать код доступа к базе данных? Ну, вы бы хотели интегрированный тест. Здесь будет использоваться реальная база данных, и вы можете создать код, который читает/записывает в базу данных. Естественно, это будет медленным и потребует данных семян. Дело в том, что вы тестируете эти автономные системы, остальное приложение будет использовать подделки в памяти. Поэтому в приведенном выше примере, пока DatabaseStore работал сам по себе, мы могли бы быть уверены, что остальная часть кода сделала правильную вещь.

Answer 2

Что я делаю, сначала реализую мои методы CREATE, и я тестирую их, напрямую запрашивая базу данных и не через мои методы READ DAD. Когда они пройдут, вы можете написать свои тесты READ, используя методы CREATE, чтобы заполнить базу данных тестовыми данными, а затем реализовать свои методы READ.

Что касается настройки и разрыва базы данных после каждого теста, поместите SQL для этого в свои методы настройки и удаления.