我正在使用WIX构建合并模块。调用WIX工具从* .wxs文件生成合并模块的批处理文件由我的每日构建运行。
我试图找出如何自动化这些合并模块的测试。我想测试的是，合并模块是否安装了所需的文件，文件的版本是否正确等等。
我的一个想法是编写一个脚本（可能是VB脚本）来在临时位置安装合并模块，并检查它是否已正确安装。但是，我不确定这是否是一种正确的方法。
是否有任何标准方法可以为合并模块编写单元测试？关于如何解决这个问题的任何想法都是受欢迎的。
答案 0 :(得分：3)
测试安装程序时，主要目标是验证
msiexec报告成功（即返回代码0）。 第一点应该很容易做到，但如果要保持测试自动化，则只能测试非交互式安装。以下是如何从批处理文件或命令行执行此操作的示例：
msiexec /i myinstaller.msi /passive || echo ERROR: non-zero return code!
第二点有点复杂。我认为实现这一目标的最佳方法是在应用程序中构建一些集成测试，并在安装后调用这些测试：
"c:\program files\mystuff\app.exe" /selftest || echo ERROR: non-zero return code!
在您的情况下，您正在测试合并模块而不是整个安装程序。可以使用相同的方法。您只需要进行额外的工作来构建“自检”应用程序及其使用合并模块的安装程序。
答案 1 :(得分：1)
您可以尝试使用脚本或其他可以完成工作的小型控制台程序，就像您建议的那样。
使用构建过程，您还可以构建仅使用合并模块的基本设置。你的脚本可以只安装它，运行另一个脚本或控制台应用程序，它将检查所有文件是否到位，它们是否具有正确的版本，是否安装了所有注册表项等。在收集完所有输出之后脚本只会卸载所有内容。您还可以在卸载后运行检查程序，以确保一切都已消失并且卸载正常。例如，如果您为安装和卸载设置了自定义操作，我建议您这样做。
理想情况下，整个安装/卸载过程应在单独的计算机或虚拟计算机上完成，以避免弄乱构建服务器。
您将对所有这些脚本进行一些工作，但是一旦拥有它，您将能够使用它，对于任何其他未来的合并模块项目或仅仅是简单的安装项目几乎没有变化。
希望这会有所帮助，
阿德里安。
答案 2 :(得分：1)
我经常想到这一点，但没有想出任何我喜欢的东西。首先，我称这种集成测试不是严格的单元测试。其次，“正确文件”和“正确版本”的问题很难定义。
我经常试图说WiX / MSI只是定义安装程序要做什么的数据。它本质上是声明性的，因此根据定义是正确的。很想要创建另一组数据来交叉检查安装程序的实现，但实际上第一个数据集尚未代表什么呢？有时很难维护哪些文件单独进入应用程序以维护第二个文件列表。
我继续考虑这一点并想知道是否有一种方法是有意义的，但此时我只是进行正常的MSI验证。