我应该编写哪些数据库测试,以便轻松地重构数据库

时间:2009-01-14 17:28:33

标签: database refactoring agile

是否有关于编写数据库测试的指导原则,以便您可以在进行进化数据库设计时“无所畏惧”地重构数据库?

在开发数据库时,应该对数据库的哪些方面进行测试?任何一个例子都会很棒..

4 个答案:

答案 0 :(得分:2)

我编写调用我的dal代码的测试,并在检查插入/更新/删除是否实际发生之后,所谓的状态测试。这些是pr定义而不是单元测试,而是集成测试,但它们实际上帮助我多次进行数据库更改。随着时间的推移,我有了更多更好的测试,甚至更大的数据库更改也相当无缝。

答案 1 :(得分:1)

根据TDD的说法,测试的概念是你测试现在的工作方式现在。当您需要更改某些内容时,可以更改解决该问题的测试(确保当前代码库失败),然后更改代码,直到测试通过。没有改变的测试让你相信你的软件的其他方面仍然在做以前所做的事情,并且你的重构没有破坏任何东西。

所以你不要在考虑重构的情况下编写测试;相反,您测试您的需求,然后当您的需求发生变化时,您相应地更新测试,并重构代码,以便它通过新的测试

答案 2 :(得分:0)

始终担心您对数据库所做的每一项更改。这将迫使您仔细检查您更改的每件事情并缩小可能的错误。

请记住,数据库通常是一个或多个应用程序的支柱,因此您所做的每项更改都必须仔细规划并进行适当测试。

答案 3 :(得分:-1)

在编写存储过程时,我自由地添加了Debug / Print语句。使用@Debug作为bit:

类型的输入参数
IF @Debug = 1 PRINT @MyDynamicVariable