如何组织实时数据完整性测试和代码单元测试?

时间:2010-04-25 08:00:57

标签: database unit-testing automated-tests nosql data-integrity

我有几个包含代码测试代码的文件(使用“unittest”类)。

后来我发现测试数据库完整性也很好。我把它放到一个单独的目录树中。 (像键的格式正确,父节点和子节点指向正确等等。编辑:这是一个nosql项目,我不能依赖数据库级别检查谎言参照完整性等。)

我使用相同的unittest类进行完整性测试。

现在我想知道保持这种分离是否真的有意义。为了测试数据的完整性,我经常复制用于测试处理数据的代码的代码部分。

但它不一样。代码测试使用测试数据库(在每次测试后删除),完整性测试连接到实时数据并进行分析。我想从cron调用完整性测试,并在实时数据库中发生事件时发送警报。

你会怎么处理?这样的设置有标准吗?你有什么经历?

我倾向于将所有内容放在同一个文件中,这会导致代码测试也由生产环境中的cron执行。

编辑:同样让我感动的是尝试保持项目简单,不要让单个任务或工作流程触及太多文件。没有所有的测试,我已经有了一个类文件,一个子类,一个相关的类,一些库(帮助器)文件和主代码。测试添加一个文件。它有助于我在编码时保持注意力集中,压力更小,我相信我减少了错误,我可以更快地记住并找到一个特定代码部分,减少受影响的文件。每个工作流程只有一个测试文件可以帮到这里如果我保持它是单独的,有2个文件(数据完整性测试和代码测试),也许3个(两者的公共库)。抽象会增加复杂性。

Edit2:我现在正在重构一点,只将数据测试文件移动到代码测试所在的同一目录树中,但保留名称为“完整性”的不同文件或“测试”。我不会(还)合并这些文件,因为2个人建议反对它,我相信他们现在的经验和建议。我现在将使用代码重复。

Edit3:我忘了提到每次运行的测试选择不是由这种情况下的树结构决定的。测试在主文件中枚举,因此我目前有2个主文件“完整性”和“代码测试”,并且测试可以存在于相同的直接结构中。

也许会有更多人回答。到目前为止,感谢您提供的宝贵意见,这已经帮助我开发了最终结构!

Edit4:我现在做了更多的重构。我似乎应该保留2个文件,但目的略有修改。一个针对生产服务器上的计划监视。另一个用于开发。但在这两个文件中都可以进行完整性测试或代码测试。在两个文件中,可以在测试数据库(在测试之后擦除)和永久数据库(每个都有永久数据库,生产服务器和开发服务器)上执行操作。还有一件重要的事情:我发现自己将大量常用代码从测试文件移到了类文件中。所以这些课程也获得了仅用于测试的能力。到目前为止我喜欢这个,感觉很干净。我还没有(还)创建一个在两个测试前端之间共享的测试库,这段代码已经转到了目前正在考虑的obejct的类文件中。

请注意,我在下面的评论是用“user89021”签名的,但是我是karlthorwald。我无能为力。

3 个答案:

答案 0 :(得分:4)

你将它们分开的方法很好。

您对代码重复的担忧是100%有效。

解决方案是相当直接的 - 抽象的测试之间的共同功能 - 例如“RunTest”,“AnalyzeResult”,“ConnectToDB” - 进入一个公共库(你没有指定哪种语言,但我认为它有一个库的概念),可以传递移植详细信息,例如连接到哪个数据库。

然后独立于单元测试驱动程序和完整性测试驱动程序使用该库 - 如果您熟练/幸运的话,除了配置之外可能只有很少的代码(例如,连接到哪个数据库,如何报告)结果,以及要运行的测试。)

同样,如果需要,可以将公共输入/数据集放在公共目录

答案 1 :(得分:4)

您应该将数据库相关测试与“纯”单元测试分开 考虑到好处,拥有两个不同程序集的成本非常低 - 您可以在任何计算机上运行一套快速,无需环境设置的测试,以及测试只能在特定位置运行的数据库完整性的较慢套件(例如构建服务器)。

另一个好处是你可以有两个运行不同测试套件的构建过程(快速和夜间)。

为避免重复代码,您可以使用两个测试套件所需的常用方法/操作创建另一个程序集。不要过分担心重复实际测试,因为你正在测试不同的东西(逻辑或数据库),所以你的测试迟早会根据你想要测试的内容而变得非常不同。

答案 2 :(得分:0)

还有一个答案。您有两种类型的测试。我想做的是解决完整性测试。您可能想要做的是将完整性测试作为生产代码的函数。 IOW,将完整性作为系统的一部分。

您已经提到重复是一个问题,并且您正在重构以删除重复。重构的代码当然有开发测试吗?

系统监控可以是生产代码。因此,您编写的代码将成为系统的一部分。

关于这一点的好处是你通过开发测试来改进你的代码。