数据清理,验证和测试驱动开发

时间:2014-01-23 21:17:42

标签: unit-testing validation testing

我正在使用连接到外部供应商的应用程序。数据异步到达,许多应用程序的“组件”使用这些数据。数据在进入系统之前已通过语法验证,但每个“组件”根据自己的规则对数据是否可用有不同的定义。

在考虑每个组件的测试驱动开发时,关于清理+数据验证的设计的“最佳实践”是什么?假设COMPONENT1_VALIADTION和COMPONENT_1具有单独的测试用例。如果数据首先通过上面的COMPONENT1_VALIADTION,那么测试用例和component_1,2,3的实现是否可以接受清理数据?可能那么系统测试可以确保在调用component_x之前清理数据吗?

EXTERNAL_DATA_SOURCE -> [ASYNC_CALLBACK -> COMPONENT1_VALIADTION -> COMPONENT_1]
EXTERNAL_DATA_SOURCE -> [ASYNC_CALLBACK -> COMPONENT2_VALIADTION -> COMPONENT_2]
EXTERNAL_DATA_SOURCE -> [ASYNC_CALLBACK -> COMPONENT3_VALIADTION -> COMPONENT_3]

理论上它也可能看起来像:

EXTERNAL_DATA_SOURCE -> [ASYNC_CALLBACK -> [ COMPONENT1_VALIADTION -> COMPONENT_1] ]
EXTERNAL_DATA_SOURCE -> [ASYNC_CALLBACK -> [ COMPONENT2_VALIADTION -> COMPONENT_2] ]
EXTERNAL_DATA_SOURCE -> [ASYNC_CALLBACK -> [ COMPONENT3_VALIADTION -> COMPONENT_3] ]

测试的组件是[COMPONENT1_VALIADTION - > COMPONENT_X。这样每个组件都包含验证本身。但是,如果我想要使用相同的验证规则的多个组件,或者想要分别实际测试验证组件,这会使事情复杂化?

我正在努力避免需要数据验证的应用程序的每一层......

提前致谢,

curious1

1 个答案:

答案 0 :(得分:0)

如果我理解你的问题,这似乎更像是一个设计问题,而不是单元测试问题。根据数据验证的复杂程度,将数据验证组件与应用程序的实际组件分开可能是一个非常好的主意。这样,查看组件的开发人员不必浏览所有验证代码。此外,如果您可以跨多个不同的组件重用相同的验证组件,这可能是一个很好的设计决策。

您需要做的是为每个组件制定“合同”。这很可能只是以类和方法文档的形式解释了这个组件期望输入的内容以及它将作为输出返回的内容。然后,您将编写单元测试,确保您的代码符合该合同。如果component1不是为处理无效数据而设计的,则不需要为其编写单元测试,因为它不是合同的一部分。您将对验证组件执行相同的操作。

现在,您的开发人员需要确保以您描述的方式构建应用程序,以便在常规组件之前调用验证组件。您可以在此处执行一些集成测试,以确保所有组件都正确连接。

我对这个问题感到有些困惑,所以我希望这会有所帮助。