单元测试组件耗尽进程
有人有测试“进程外组件”的经验吗？ 我正在测试一些配置为在进程外激活的 Com+（服务组件）和 WCF 服务，我不确定在这些情况下进行测试的最佳实践是什么。
我所做的就是为公共类提供它们自己的 IOC 容器，它们可以在激活时构建它们。 这工作正常，但是当我尝试进行单元测试时，我会遇到问题，原因有两个...
我想要注入的任何依赖项对象都需要可序列化，因为单元测试在不同的进程中运行。 如果我想将附加模块 (ninject) 加载到 com+ 内核/ioc 容器中，我需要编写自己的模块以使其可序列化。 我不愿意仅仅为了进行测试而将事物序列化。
进程外程序集需要安装到 GAC 中，并且在 Com+ 的情况下需要注册。 这使得测试变得很痛苦，因为在测试之前需要安装它们。
目前我只能想到两种方法来解决这个问题。
有一个单独的工作副本用于运行测试，我在其中修改了配置以运行进程中的程序集。 显然这并不理想，因为现在我正在修改代码只是为了使其可测试。 尽管我可以接受这个，因为它不涉及任何功能更改。
让单元测试继承自 Com+ 或 WCF 组件，以便测试可以在同一进程边界中运行。 （这需要将单元测试安装到 GAC 中）
Anybody out there have experience testing "out of process assemblies"?
I'm testing some Com+ (Serviced Component) and WCF services configured to be activated out of process and I'm not sure what the best practices are for testing in these situations.
What I've done is given the public classes their own IOC container that they can build up upon activation. This works fine but I run into problems as soon as I try and unit test for 2 reasons...
Any dependency object I want to inject needs to be serializable because the unit tests are running in a different process. If I want to load an additional module (ninject) into to com+ kernel / ioc container I need to write my own to make it serializable. I don't feel comfortable making things serializable just to do tests.
Out of process assemblies need to be installed into the GAC, and in the case of Com+ need to be registered. That makes testing a pain since they will need to be installed before they are tested.
I can only think of two ways to approach this at the moment.
Have a separate working copy for running tests where I've modified the configuration to run the assemblies in process. Obviously this isn't ideal because now I'm modifying code just to make it testable. Although I could live with this because it doesn't involved any functional changes.
Have the unit test inherit from the Com+ or WCF component so the tests can run in the same process boundary. (This would require the unit test to be installed into the GAC)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一般来说，我会为一个进程中的组件和另一进程中的组件编写测试，而不必担心中间的点（只需让它们尽可能薄）。
如果您正在测试两个独立进程之间的交互，我认为这几乎是定义上的集成测试。
Generally, I'd write tests for the components in one process, and the components in the other process, and not necessarily bother with the points in the middle (just keep 'em as thin as possible).
If you're testing the interaction between two separate processes, I think that's an integration test almost by definition.
我会同意你的第一个建议：有一个单独的工作副本来运行测试，其中程序集在进程中运行。
优点是：
一旦您在您的系统上运行此功能，它将在其他团队成员的计算机上运行，无需任何配置。
一旦
测试的运行速度将显着加快，因为您没有进行进程间调用。
测试
我记得当我第一次开始测试驱动开发时。 和您一样，我不愿意仅仅为了适应自动化测试而更改我的代码。 我逐渐改变了自己的心态。 这些库需要服务两个同等重要的客户端：生产客户端代码和测试。
I would go with your first suggestion: Have a separate working copy for running tests in which the assemblies are run in process.
Advantages are:
Once you have this working on your system it will run on other team member's machines without any configuration.
The tests will run significantly faster because you're not making interprocess calls.
I remember when I first started test-driven development. Like you, I was reluctant to change my code just to accomodate the automated tests. I gradually changed my mindset. The libraries need to serve two equally important clients: the production client code and the tests.