我有一个任务是在本机activex组件周围编写.net包装器,它可以加载股票价格的实时数据。
问题是如何正确测试?
我做出以下测试用例似乎是合理的:
不幸的是:
当然,我可以模拟数据源,这会有所帮助。但是在这种情况下,我会测试我的包装器是否能够防止我自己,而不是那些编写本机加载器的人
答案 0 :(得分:1)
非确定性和单元测试不能很好地结合在一起。但是,我认为你所面临的唯一非确定性是从本机加载器接收的数据及其格式。为什么呢?
测试它的工作原理:开始在某个代码上加载价格,确保加载开始
这应该完全由.NET代码控制;通过某种工作或手动方法调用。没有非决定论。
测试数据正在流动:开始在某些代码上加载价格,确保我收到了一些更新
再次,.NET代码。您可能需要另一个可以定期查询本机加载程序以获取数据的作业,或者需要从本机加载程序中查看事件并响应它们的内容。
测试我的价格是否合理:开始在某些代码上加载价格,确保我已收到预期价格(或至少在合理范围内的价格)
什么是合理的价格?范围从0
到Int32.Max
? 不要尝试测试本机加载程序。 假设它是如何工作的并围绕这些假设构建代码。您当然可以验证数据格式,范围(例如,价格不应该是负值),但这是关于它的。这将我们带到您可能希望进行单元测试的实际代码 - 将他们的数据映射到您的数据的类(域对象 - 一个简单的POCO - StockQuotation
或TickerData
)。某些种类的构建器/映射器/转换器。
现在,您希望有两组测试 - 一组用于构建器/映射器代码,以确保您的后续代码适用于您所做的假设。第二组是传统的系统/集成测试 - 从使用实际组件加载数据到构建结果的整个过程(你不应该关心这里的代码不再存在,因为那些超出你的控制)。
在这样的设置中,如果某些东西停止工作,通常可能意味着两件事之一:
此时跟踪问题应该很容易。不要试图编写万无一失的代码,因为你不会。有bug的代码是正常状态。你找到并修复它们。准备错误/异常比尝试编写不包含它们的代码要容易得多。更不用说,你无法真正控制第三方代码中的错误(你的本地加载程序) - 最好为它们做好准备。