有效地测试数据库后端

我有一个数据库支持的应用程序，很遗憾，它的数据库测试很少。我试图快速有效地测试数据库。有效地测试数据库后端

到目前为止，我已经学会：

测试的应用程序把/获取数据到数据库
使用模拟DB的测试对象/关系映射代码

的能力

我仍然在努力实现第一点。看来，测试的唯一方法是将数据插入到真正的表中。但是用户当然不希望看到我的测试数据。这是我目前在做的伪代码：

begin a transaction 
insert a few rows 
check that no error has occurred 
'select' the rows back out 
check that no error has occurred, check that data out matches data in 
tell the test framework that it's successful 
abort the transaction

这是一个最佳实践，或某种可怕的反模式？有更好的建议吗？

来源

2011-11-22 Matt Fenwick

您的用户绝对不应该看到您的测试数据，因为在生产测试是非常糟糕的做法！您应该尝试创建测试环境并在那里进行测试。

我发现的一个解决方案是创建一个单独的数据库实例，用一些已知数据填充它，并将其用于集成测试。确保在每个测试用例之后清理数据库，因为测试用例应该是独立的。

在测试数据库中使用事务并不是一个很糟糕的做法，因为您可以确认事件并回滚事务，但是我担心您会调用将提交到数据库的代码，从而改变以下测试的参数。当然，如果你的数据库支持嵌套事务，这不是什么大问题，但是ISTM并不是所有的数据库都这么做。

来源

2011-11-22 16:47:19 Kane

+1，因为我觉得你提一些好点，但我不知道我理解为什么'在生产测试是非常糟糕的practice'。我会认为这是一个很好的做法 - 因为数据库测试的一点是验证用户计算机上的应用程序是否可以与用户计算机上的数据库交谈，即所有内容都已正确安装。 OTOH，在检查数据库模式是否应用程序期望的情况下，该语句对我来说是有意义的。 –

一个坏主意，你提出的原因！让我们说测试中出了问题，你不想要软管你的生产环境。您也不想用测试数据污染您的生产数据库，这使得难以对生产数据执行度量标准，偶尔会导致客户想知道发生了什么。此外，通过测试数据库，您可以控制内容 - 这允许您进行真正的呼叫，获取用户数量并对其进行测试，而数据在生产中不断变化。 – Kane

超出评论空间。在行业最佳实践中，至少有三种环境：生产（duh），测试（因此您可以使用已知数据在产品投入生产之前检查更改）和开发（因为开发人员经常在弄清楚事情的同时弄糟东西，而您不希望开发出干扰测试或更糟，生产的功能）。 – Kane

-2

是的，我们应该有3个不同的环境，如dev，qa和生产环境。您不应该使用生产数据，因为有时候数据会复制到某些分布式数据库，并且如果您不知道复制，将会产生不必要的问题。

〜Temruzinn

来源

2016-05-26 09:39:47 Temruzinn

有效地测试数据库后端

回答

相关问题