我有一个项目,其中的大多数挑战是确保软件与几个外部系统输出的平面文本文件一起正常工作.
Mangement决定引入敏捷和TDD作为特定实现.
我发现从平面文件中模拟输入是没有意义的,因为要解决的主要问题是使用这些特定文件完全正确的工作.
例如,如果外部系统的输出发生变化,则单元测试必须失败
对从文件中提取的代码进行单元测试几乎没有意义,并且创造的商业价值很小(因为抽象代码需要花费大量时间进行抽象,而实际上将产生一百行方法).
只是想重申一下 - 面临的挑战是如何在软件上保留一个能够处理平面文件的标签,而TDD则可以随时对其进行验证.
会有什么建议？如何组织,定义和实施？
在测试项目中包含示例文件,并使用这些文件进行测试.我倾向于将文件构建到测试程序集中并用于Assembly.GetManifestResourceStream将其传递给代码.在API中使用Stream或TextReader表示您可以使用测试代码本身中的数据MemoryStream或StringReader使用测试代码中的数据进行非常小的测试.(除非你需要担心检测编码,否则使用a TextReader可能比a更合适Stream.)
你可以做一切有StringReader,但以我的经验,如果你结束了测试数据的几行就可以得到相当混乱-单独的文件中可以更容易看到所涉及的数据.
请注意,这不会检查外部系统的输出是否没有改变 - 正如Pontus所说,这将涉及系统/集成测试.但是,根据我的经验,您不希望在该级别进行大部分测试.您应该在不同级别进行混合测试,但测试级别越高,可能需要运行的时间越长 - 并且设置起来越困难.
您可能需要仅测试外部系统的测试:拥有一段您希望从外部系统接收的样本数据,并对您的代码进行一次单元测试以测试其行为是否恰当,以及一个"外部"测试调用外部系统并检查它们产生的确切文件.这样,您可以很快地判断出故障是由于您的代码更改还是外部系统发生变化.
| 归档时间： |
|
| 查看次数： |
660 次 |
| 最近记录： |