单元测试数据库访问层

时间:2012-02-18 15:49:18

标签: python database unit-testing

我知道之前已经多次询问过这个问题,但我有一些具体的代码示例,我想知道对它们进行单元测试是否有意义:

class FooAPI(object):

    def create(self, prop1, prop2, prop3, prop4, prop5):
        sql = "INSERT INTO foo (prop1, prop2, prop3) VALUES (?, ?, ?)"
        self.connection.execute(sql, (prop1, prop2, prop3))

        foo_id = self.connection.insert_id()

        sql = "INSERT INTO foo_settings (foo_id, prop4, prop5) VALUES (?, ?, ?)"
        self.connection.execute(sql, (foo_id, prop4, prop5))

        return foo_id

    def update(self, foo_id, prop1, prop2, prop3, prop4, prop5):
        "Update code similar to above"

    def delete(self, foo_id):
        sql = "DELETE FROM foo WHERE foo_id = ?"
        self.connection.execute(sql, (foo_id,))

    def find(self, foo_id=None, prop1=None):
        "Find objects by ID or by prop1"

对上述代码进行单元测试是否有意义,以及如何解决这个问题。这里有两个复杂的因素:

  • 数据库本身并不简单,我目前没有简单的方法来创建包含所有测试数据的数据库
  • 架构正在发展,这意味着无法一劳永逸地创建测试数据库。

2 个答案:

答案 0 :(得分:0)

根据您的要求,测试代码总是有意义的。那就是说,你在这里做的很简单,可能不需要测试。但是,我认为即使很难建立一个测试数据库,你也很可能在以后需要它,所以当你不想做一些复杂的事情的时候你也可以这样做。此外,它发现架构正在发展。随着时间的推移,数据库的主要变化几乎是不可避免的,你只需要随之而来。

我能想到不测试的唯一理由就是你希望尽快完全改变数据库。

答案 1 :(得分:0)

单元测试(即没有数据库),而不是IMO。集成测试通常我认为这是一个好主意。

  

数据库本身并不简单,我目前没有简单的方法来创建包含所有测试数据的数据库

如何维护架构?在你前进之前,你需要做到这一点。 您是否可以在一个自动步骤中从空白数据库转到至少具有模式的数据库?我猜不是如此,如果你没有一个好的系统来保持数据库更新,Liquibase可以帮助你。

现在测试数据 - 保持所需的数据很小。