如何使用第三方库对使用第三方库转换某些文件的代码进行单元测试

时间:2018-01-19 04:53:11

标签: unit-testing junit mocking apache-fop

我正在使用一些XSL样式表对XML文件进行转换,并使用Aache FOP生成PDF文档(详情here)。参考Java代码片段如下所示:

/// <reference types="opentype.js" />

public byte[] writePdf(String xml, FopFactory fopFactory, Transformer transformer) StreamSource xmlStream = new StreamSource(new StringReader(xml)); //fop: try (ByteArrayOutputStream out = new ByteArrayOutputStream()) { Fop fop = fopFactory.newFop(MIME_PDF, out); Result res = new SAXResult(fop.getDefaultHandler()); transformer.transform(xmlStream, res); return out.toByteArray(); } } 实例和Transformer是从外部注入的。 简而言之,该程序使用“Java XML”和“Apache FOP”API来编写使用某些XSL和XML资源的文档。
关于如何对这件作品进行单元测试的想法?测试是否还需要访问XML和XSL资源,这是否很好?

修改
什么可以轻松完成:

  • 通过提供模拟的Transformer实例来测试是否已调用方法FopFactory

有什么问题:

  • 验证结果transform。这是一个正确的结果还是只是一个阵列?
  • 是否在转换过程中使用了提供的xml字符串?

这样做的一种方法是提供测试中的实际XML,XSLT资源,并将输出流与预期进行比较。对我来说,这似乎很脆弱,因为如果底层使用的API的输出甚至略有变化,这很容易破坏。此外,这也是不够的,因为它只能测试一个硬编码的测试场景。

使用过的API本身是不可测试的还是可以改进?

1 个答案:

答案 0 :(得分:1)

测试为给定输入生成的输出。然而测试二进制输出(字节)真的很脆弱。因此,尝试从输出中获得更易读的模型。

您可以使用pdfbox重新分析/解析输出。这提供了一个可以断言的模型。最好只断言你期望的相关属性而不是完整的pdf结构,因为后者可能几乎和二进制代码一样脆弱。

此外:即使测试一些示例输入的二进制输出也比完全不测试更好。