如何对 WIX 合并模块进行单元测试？
我正在使用 WIX 构建合并模块。调用 WIX 工具从 *.wxs 文件生成合并模块的批处理文件由我的日常构建运行。
我试图弄清楚如何自动化这些合并模块的测试。我想测试的是，合并模块是否安装了所需的文件，文件的版本是否正确等。
我的一个想法是编写一个脚本（可能是VB脚本）来在临时位置安装合并模块并检查它是否已正确安装所有内容。但是，我不确定这是否是正确的方法。
是否有为合并模块编写单元测试的标准方法？欢迎任何有关如何解决此问题的想法。
I am building merge modules with WIX. The batch files which calls the WIX tools to generate the merge modules from *.wxs files are run by my daily build.
I am trying to figure out how could I automate the testing of these merge modules. Things I would like to test are, whether the merge module installs required files, whether the versions of the files are correct etc.
One idea I have is to write a script (may be VB Script) to install the merge module at a temporary location and check if it has installed everything correctly. However, I am not sure if this is a correct way to do it.
Are there any standard ways of writing unit tests for merge modules? Any ideas around how to go about this are welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
测试安装程序时，主要目标是验证
msiexec报告成功（即返回代码0）。第一点应该很容易做到，但如果您想保持测试自动化，则只能测试非交互式安装。下面是如何从批处理文件或命令行执行此操作的示例：
第二点有点复杂。我认为实现此目标的最佳方法是在应用程序中构建一些集成测试，并在安装后调用这些测试：
在您的情况下，您正在测试合并模块而不是整个安装程序。可以使用相同的方法。您只需要完成构建“自测试”应用程序及其使用合并模块的安装程序的额外工作。
When you test an installer, the primary goals are to verify that
msiexecreports success (i.e. return code0).The first point should be easy enough to do, though if you want to keep the test automated you can only test the non-interactive install. Here is an example how to do that from a batch file or on the command line:
The second point is a bit more complicated. I think the best way to achieve this is to build some integration tests into your application, and invoke those tests after the install:
In your case you're testing a merge module rather than an entire installer. The same approach can be used. You just will have to do the additional work of building a "self test" application and its installer which consumes your merge module.
我经常思考这个问题，但没有想出任何我喜欢的东西。首先，我将此称为集成测试，而不是严格的单元测试。其次，“正确的文件”和“正确的版本”的问题很难定义。
我经常想说 WiX/MSI 只是定义安装程序要执行的操作的数据。它本质上是声明性的，因此根据定义是正确的。人们很容易想要创建另一组数据来交叉检查安装程序的实现，但是这到底能完成第一个数据集尚未代表的什么呢？有时维护哪些文件进入应用程序已经够困难的了，但又要单独维护第二个文件列表。
我继续思考这个问题，想知道是否有一种方法有意义，但此时我只是进行正常的 MSI 验证。
I've often thought about this but haven't come up with anything that I like. First I would call this integration testing not strictly unit testing. Second the problem of "right files" and "right versions" is difficult to define.
I'm often tempted to say WiX/MSI is just data that defines what the installer is to do. It's declarative in nature and therefore by definition correct. It's tempting to want to create yet another set of data that cross checks the implementation of the installer but what exactly does that accomplish that the first data set didn't already represent? It's hard enough sometimes to maintain what files go into an application yet alone to maintain a second list of files.
I continue to think about this and wonder if there's an approach that would make sense but at this point I just do my normal MSI validation.
您可以尝试使用脚本或其他小型控制台程序来完成这项工作，就像您建议的那样。
通过构建过程，您还可以构建仅使用合并模块的基本设置。您的脚本可以安装它，运行其他脚本或控制台应用程序，该应用程序将检查所有文件是否就位、它们是否具有正确的版本、所有注册表项是否已安装等。收集所有输出后，您的主脚本只会卸载所有内容。您还可以在卸载后运行检查程序，以确保一切都消失并且卸载正常进行。例如，如果您为安装和卸载设置了自定义操作，我会建议您这样做。
理想情况下，整个安装/卸载过程应在单独的计算机或虚拟计算机上完成，以避免弄乱构建服务器。
您将需要对所有这些脚本做一些工作，但是一旦拥有它，您将能够在任何其他未来合并模块项目或只是简单的安装项目中进行少量更改来使用它。
希望这会有所帮助，
阿德里安。
You could try to use scripts or other small console program that will do the job, just like you suggested.
With your build process you could also build a basic setup that just uses the merge module. Your script could just install this, run the other script or console app that will check if all the files are in place, that they have the correct version, that all the registry keys are installed, etc. After all the output is gathered your main script would just uninstall everything. You could also run the check program after uninstalling to be sure that everything is gone and that the uninstall works correctly. I would recommend this if, for example, you have custom actions set for install and uninstall.
Ideally this whole install / uninstall process should be done on a separate machine, or a virtual one, in order to avoid messing up the build server.
You'll have some work to do with all this scripts but once you have it, you'll be able to use it with little changes for any other future merge module projects or just plain setup projects.
Hope this would help,
Adrian.