答案:数据库程序的单元测试
本文来自互联网,原作者不详。
翻译:PMTeam Xu NingNing
这些笔录是我关于已完成的数据库功能测试的一些心得。其中的例子是用java语言编写的,但我认为这些想法对于大多数编程环境都普遍适用。当然,我仍致力于寻找更佳的解决方案。
现实的问题是这样的:你有一个SQL数据库,一些存储过程和一个介于应用程序和数据库之间的中间层。你怎样在其中插入测试代码从而保证在数据库中数据存取功能的实现?
一、 为什么会有这样的问题?
我猜想有些,可能不完全是大多数的数据库开发过程都是这样的:建立数据库,编写存取数据到数据库的代码,编译并运行,用一个查询语句查验所列的数据是否正确显示。如果能正确显示那就大功告成了。
然而,这种靠眼睛来检测的弊端在于:你不经常进行这样的检验,而且这种检验是不完全的。存在这样的可能性,当你对系统进行了修改,过了几个月后,你无意中破坏了系统,从而导致数据的丢失。作为一个编程人员,你可能不会花很多时间来检查数据本身,这就使错误的数据要经过较长的时间才能暴露出来。我曾经参与一个建立网站的项目,该项目中在注册时有一个必填数据在大半年中没有被发现未实际输入进数据库。尽管公司市场部曾经提出他们需要这一信息,但因为这项数据从来没有人去看它,直接导致了这一问题在很长时间内没有被发现。
自动化测试,由于它能经常测试而且测试范围较广,降低了数据丢失的风险。我发现它能使我更心安理得地休息。当然,自动化测试还有其他一些好处,他们本身就是代码编写的范例,也可以作为文档,便于你修改别人编写的原始程序,从而减少检测所需的时间。
二、 什么是我们所谈论的测试?
设想有一个非常简单的用户数据库,包括用户电子信箱和一个标志,用来指示邮件地址是否被弹回。你的数据库程序应该包括插入、修改、删除和查询等方法
插入方易做图调用一个存储过程将数据写入数据库。为了叙述方便,这里省去了一些细节,大致的程序如下所示:
public class UserDatabase
{
...
public void insert(User user)
{
PreparedStatement ps = connection.prepareCall("{ call User_insert(?,?) }");
ps.setString(1, user.getEmail());
ps.setString(2, user.isBad()); // In real life, this would be a boolean.
ps.executeUpdate();
ps.close();
}
...
}
而我认为的测试代码应为:
public class TestUserDatabase extends TestCase
{
...
public void testInsert()
{
// Insert a test user:
User user = new User("some@email.address");
UserDatabase database = new UserDatabase();
database.insert(user);
// Make sure the data really got there:
User db_user = database.find("some@email.address");
assertTrue("Expected non-null result", db_user != null);
assertEquals("Wrong email", "some@email.address", db_user.getEmail());
assertEquals("Wrong bad flag", false, db_user.isBad());
}
...
}
可能你还有更多测试代码。(注意一些测试,例如对date类的测试)。
assertTrue和assertEquals方法进行条件测试。如果测试失败,他们将返回诊断消息。其重点是这些测试都基于一个测试框架自动执行,并给出测试成败的标志。这些测试都基于用java语言编写的测试框架Junit类(程序附后)。这一框架也能适应其他诸如C, C++, Perl, Python, .NET (all languages), PL/SQL, Eiffel, Delphi, VB等语言环境。
下一个问题就是:我们有测试,但我们怎样保证测试数据和实际数据能严格区分?
三、 不同的鉴别方法
在开始之前,我必须指出你最好有一个测试用的数据库,你可能更想在非正式的数据库中实践我讲的东西。
第一种方法是手工在数据库中输入一些预先知道的测试性数据,例如在邮件地址中输入“testuser01@test.testing”。如果你正在测试数据库的查询功能,你能预先知道,比如说有五个,数据库记录是以“@test.testing”结尾的。
由以上方式插入的数据必须由测试本身进行必要的维护。例如,测试必须负责删除所建立的测试数据,而避免对实际数据进行操作,从而保证整个数据库处于完好状态。
这种方法还是存在以下问题:
l 你不得不和其他编程人员进行数据协调——假设他们也有他们自己的测试数据库。
l 在数据库中有些特殊的数据并不正确,如一些特别的邮件地址和被保留饿编号前缀。
l 在某些情况下,你将不能用一些特殊的数据来区分测试数据和实际数据,这就比较棘手。例如,某条数据由一些整数型字段构成,而作为测试用的数值都看起来较为合理。
l 你的测试只限于你为测试所保留的某些特殊值,这意味着你将小心地选择那些特殊值。
l 如果数据对时间敏感,那对数据库的维护将更为困难。例如,数据库中有产品销售提议,而该提议只在明确的时间段里有效。
我曾经试着做过修改。例如,在数据库中增加“is_test”字段作为区分测试数据的标志,从而避免特殊值的问题。但由此带来的问题是,你的测试代码将只测试那些标记为测试的数据,而你的正式代码却要处理那些未标记为测试的数据。如果你的测试在这方面有区别,你事实上并不在测试同一代码。
四、 你需要四个数据库
有些想法认为一个好的测试是足够充分的并能建立测试所需要的全部数据。如果你能在测试进行前就明确知道数据库所处的状态,测试可以进行一些简化。一个简化的方法是建立一个独立的单元测试数据库用于测试程序,测试程序在开始进行前清除测试数据库中的全部数据。
在代码中,你可以编写一个dbSetUp方法,如下所示:
public void dbSetUp()
{
// Put the database in a known state:
// (stored procedures would probably be better here)
helper.exec("DELETE FROM SomeSideTable");
helper.exec("DELETE FROM User");
// Insert some commonly-used test cases:
...
}
任何数据库测试程序都将在做任何事前首先调用dbSetUp方法,它将使测试数据库处于一种已知状态(大部分情况下是空数据库状态)。这种做法具有以下的优点:
l 所有的测试数据都在代码层和其他编程人员进行交流,因此没有必要进行外部测试数据协调。
l 无须测试用的特殊数据的介入。
l 简单而容易理解的一种方法。
l 在每一次测试前删除和插入数据可能会花较多时间,但是由于测试用的数据量相对较小,我认为这种方法比较快捷,特别是在测试一个本地数据库时。
这种做法不利的一面是你需要至少两个数据库。但是请记住,他们在必要是都可以在同一个服务器上运行。采用这种方法,我用了四个数据库,另外两个在紧急关头时使用,具体如下:
1. 实际使用数据库,包含实际数据。在这个数据库中不进行测试,确保数据的完整性。
2. 你的本地开发数据库,用来进行大部分的测试。
3. 一个加入一定量数据的本地开发数据库,可能和其他编程人员共享,用来运行应用程序并检测是否能在实际使用的数据库上运行,而不是照搬实际使用数据库中的全部数据。从严格意义上说你可能并不需要这一数据库,但这一数据库能确保应用程序在有
上一个:用J2EE开发WebService(4)
下一个:数据源在JDBC中的应用