我们的 msbuild 进程创建各种用于部署的 zip 包（主要是网站，但也有其他东西）。 我们遇到了各种反复出现的问题，这些问题不断地出现——包含不应该包含的文件、缺少资源。 这迫切需要自动验证。 测试的标准很简单
foosite 包的验证：
- 资源文件存在。
- 没有测试结果文件、obj 文件或其他构建工件
- 等等。
理想情况下，我可以使用大家都熟悉的 nunit 或 mstest。 Msbuild 知道包在哪里。 我们有很多包，可能在不同的分支上并发构建。 因此，包的位置和包的名称是不确定的 - 因此测试不知道包在哪里。
向 mstest 或 nunit 提供 msbuild 信息的最简单方法是什么？这个问题是一个可能的答案，但是，这个问题得到了架构建议而不是答案。 我知道这不是单元测试，但无论如何，测试框架很方便。 我可以创建一个 exe 来验证构建 - 但为什么要为项目添加几个小时呢？
或者，您对于自动验证构建包有更好的建议吗？（MSI、zip，等等）？
Our msbuild process creates a variety of zip packages for deployment (mostly web sites, but other things as well). We have a variety of recurring problems that keep sneaking back - files included that shouldn't be, missing resources. This screams for automated validation. The criteria to test for are simple
Validation of foosite package:
- Resource files are present.
- No test result files, obj files, or other build artifacts
- And so forth.
Ideally, I could use nunit or mstest, which everone is familiar with. Msbuild knows where the packages are. We have a lot of packages, possible concurrent builds on different branches. Ergo, the location of the packages and names of the packages are not deterministic - so the tests don't know where the packages are.
What is the simplest way to feed msbuild information to mstest or nunit? The answer to this question would one possible answer, however, that question got architectural advice instead of an answer. I know this isn't a unit test, but the test framework is handy, anyway. I could create an exe to validate the build - but why add a couple hours to the project?
Or, do you have a better suggestion for automatically validating build packages? (MSIs, zips, whatever)?
发布评论
评论（2）
我最终所做的是拥有一堆自定义 MS 构建任务，这些任务在虚拟服务器上启动虚拟机，将 MSI 复制到计算机上，静默部署它，然后对其进行验证。 我使用 PSExec 启动 MSI。 然后，它可以使用 MSTest 命令行运行程序使用 MSTest 并运行您的测试位。
这对您来说可能有点过分了，但是使用虚拟机可以让您干净地开始，并且不会受到开发盒上任何先前安装的影响。
What I've ended up doing is having a bunch of custom MS build tasks which spin up a virtual machine on Virtual Server, copy the MSI onto the machine, silently deploy it and then validate against it. I used PSExec to start the MSI. It could then use the MSTest command line runner to use MSTest and run your test bits.
This is probably overkill for you, but using a VM allows you to start clean and not be affected by any previous installs on your dev box.
如果您想要快速失败，例如单元测试，那么我建议您针对包创建单元测试。 这样的测试将解压缩 .ZIP 包，并对内容运行一些断言。
您甚至可以对包使用一些 TDD 技术。 例如，如果由于缺少特定文件而导致部署失败，则编写一个因文件丢失而失败的单元测试； 更改构建以使该文件存在； 然后确保单元测试成功。
但总的来说，部署问题比这更广泛，我赞同 blowdart 的建议。 部署到一台或多台虚拟机中，然后在部署的环境中运行自动化测试。 这些测试不仅会测试简单的事情，例如安装过程中是否返回错误； 他们还会检查 IIS 虚拟目录是否设置正确、属性和内容是否正确以及网站是否基本运行等。
我会使用几个不同的虚拟机来测试不同的部署场景：一个用于干净部署；另一个用于干净部署。 一个用于从版本 .-1 升级，等等。可以为每个环境运行相同或类似的 IVT 测试。
即使您不能一次完成所有这些，本练习中涉及的思考过程也应该导致对您的部署环境的实际情况有一个更正式的定义。 当您有机会在实际测试中体现这个正式定义时，这将会很有帮助。
If you want a fast fail, like a unit test, then I suggest you create unit tests against your packages. Such a test would unzip the .ZIP packages, and run some asserts against the contents.
You could even use some TDD techniques against the packages. For instance, if you have a deployment fail because a particular file is missing, then write a unit test that fails because the file is missing; change the build so that the file is present; then make sure the unit test succeeds.
But in general, deployment issues are broader than that, and I echo the suggestion from blowdart. Deploy into one or more virtual machines, then run automates tests over the deployed environments. These tests would not only test for simple things like was there an error returned during the installation itself; they would also check things like were the IIS virtual directories set up correctly, with the correct properties and contents, and does the web site basically run.
I'd use several different virtual machines to test different deployment scenarios: one for a clean deploy; one for an upgrade from version .-1, etc. It's possible that the same, or similar IVT tests could be run for each environment.
Even if you can't do this all at once, the thought process involved in this exercise should lead to a more formal definition of what your deployment environment really is. You this will be helpful when you get a chance to embody this formal definition in actual tests.