浅析数据库程序的单元测试

发布: 2010-6-17 14:08 | 作者: 不详 | 来源: 领测测试网采编 | 查看: 129次 | 进入软件测试论坛讨论

public void dbSetUp()
{
String test_db = InitProperties.get("myapp.db.testurl");
String db = InitProperties.get("myapp.db.url");
if (test_db == null)
abort("No test database configured");
if (test_db.equals(db))
{
// All is well: the database we're connecting to is the
// same as the database identified as "for testing"
}
else
{
abort("Will not run tests against a non-test database");
}
}

　　另一个技巧是，如果你有一个本地测试数据库，测试程序能通过提供IP地址或主机名进行检测。如果不是“localhost/127.0.0.1”，这就有连接在实际使用数据库上进行测试的风险。

　　关于测试日期的体会

　　如果你想存储日期信息，你大概想确认你存的日期信息是否正确。请注意以下几点。

　　首先先问自己，是谁创建该日期。如果是你的应用程序，那验证比较简单，因为你可以通过查看数据库中的具体日期进行比较。如果是数据库本身创建该日期，可能作为一个缺省字段，那你可能就会有些问题。例如，你能确保你代码所代表的时区和数据库的时区一致吗?从没有听说过数据库是以格林尼治标准时间为准显示时间和日期的。你能确保运行应用程序的计算机上的时间和数据库所在计算机上的时间保持一致吗?如果不是，你必须在进行时间的比较时留出一定的误差。

　　如果你遇到这些情况，有些事是你可以做的：

　　如果你预先知道所用的时区，在测试前将所有日期和时间全部转换成那个时区的日期和时间。

　　在比较时间时设立一定的误差，比如说几分钟、几小时或几个月。看上去缺乏说服力，但至少它能捕获诸如日期为空或1970年1月1日等错误。

　　总结

　　在本文中，我想说：

　　单元数据库测试是一件值得做的事;

　　如果你能给一系列测试程序一个对应的数据库，测试本身并不非常可怕。

　　还有其他方法能解决这一问题。我还不能确信模仿对象(Mock Object)这一方法。就我对这一方法的理解，模仿对象模拟了一个系统中间层(在本文中，是数据库操作系统)，使得模仿的数据库总能返回你想要的数据。我比较欣赏这一概念，它鼓励你对测试进行分层，可能划分成SQL方面的测试和Java语言方面的测试，从而对模仿的ResultSet对象进行测试。

　　我比较关注那些能导致一次能使两个或两个以上的数据表产生变化的操作。在这种情况下，用模仿对象方法进行数据库的维护和实现比较困难。当然，我还要找到一种好方法进行数据库中SQL方面的测试，从而确认数据被正确地存储到数据库中。