Unit Testing Assemblies Running Out Of Process

Question

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...

1. 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.

2. 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.

1. 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.

2. 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)

Answer 1

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.

Answer 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.