Как использовать TDD для создания представления базы данных существующих объектов?

Question

Я использовал TDD для разработки набора классов в Python. Эти объекты содержат поля данных, функции и ссылки друг на друга. Все функционально работает, как я хочу.

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

Я набросал некоторые возможные схемы базы данных для хранения той же информации, но я считаю, что это «внезапный большой скачок» по сравнению с традиционным способом TDD для разработки остальной части приложения.

Итак, теперь мне интересно, какие тесты следует писать, чтобы заставить меня хранить эти объекты в базе данных пошаговым способом TDD?

Изготовление этот вопрос немного более конкретными, классы в настоящее время, как это:

class Connector(object): 
    def __init__(self, title = None): 
    self.value = None 
    self.valid = False 
    self.title = title 
    ... 

class Element(object): 
    def __init__(self, title = None): 
    self.title = title 
    self.input_connectors = [] 
    self.output_connectors = [] 
    self.number_of_runs = 0 

    def run(self): 
    ... 
    self.number_of_runs += 1 

class Average(Element): 
    def __init__(self, title = None): 
    super(OpenCVMean, self).__init__(title = title) 
    self.src = Connector("source") 
    self.avg = Connector("average") 
    self.input_connectors.append(self.src) 
    self.output_connectors.append(self.avg) 

    def run(self): 
    super(Average, self).run() 
    self.avg.set_value(numpy.average(self.src.value)) 

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

Answer 1

Прежде всего, спросите себя, будете ли вы тестировать свой код или ORM Django. Хранение и чтение в большинстве случаев будут прекрасными.

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

Кроме того, используйте South или другие средства миграции, чтобы уменьшить стоимость изменения схемы. Это даст вам спокойствие.

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

def test_db_access(self): 
    input = Element(title = 'foo') 
    input.save() 

    output = Element.objects.get(title='foo') 

    self.assertEquals(input, output) 

Mocking сохранить:

def save(obj): 
    obj.id = 1