【IT168 技术文章】
现实的问题是这样的：你有一个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”结尾的。
由以上方式插入的数据必须由测试本身进行必要的维护。例如，测试必须负责删除所建立的测试数据，而避免对实际数据进行操作，从而保证整个数据库处于完好状态。
这种方法还是存在以下问题：
你不得不和其他编程人员进行数据协调——假设他们也有他们自己的测试数据库。
在数据库中有些特殊的数据并不正确，如一些特别的邮件地址和被保留饿编号前缀。
在某些情况下，你将不能用一些特殊的数据来区分测试数据和实际数据，这就比较棘手。例如，某条数据由一些整数型字段构成，而作为测试用的数值都看起来较为合理。
你的测试只限于你为测试所保留的某些特殊值，这意味着你将小心地选择那些特殊值。
如果数据对时间敏感，那对数据库的维护将更为困难。例如，数据库中有产品销售提议，而该提议只在明确的时间段里有效。
我曾经试着做过修改。例如，在数据库中增加“is_test”字段作为区分测试数据的标志，从而避免特殊值的问题。但由此带来的问题是，你的测试代码将只测试那些标记为测试的数据，而你的正式代码却要处理那些未标记为测试的数据。如果你的测试在这方面有区别，你事实上并不在测试同一代码。
