COMUnit FAQ

Q: When I run the run the test project for the COMUnitRunner, why does a Debug window come up? And what should I do about it?

A: The COMUnitRunner test project generates an exception for the purpose of catching it and displaying it in the user interface. This is fully intentional. To proceed, click the Debug button revealing the source code that triggered the exception. Right-click the code window and select Toggle->Break on Unhandled Errors from the context menu. Then continue with the execution of the project to allow the exceptions to be caught and displayed in the user interface.

Q: When an exception occurs in my test code a Debug window pops up. I want the exception to be caught by COMUnit. Why does this happen?

A: This is essentially the same issue as above. By default, for EXE Projects, Visual Basic catches exceptions in the debugger. To disable this, right-click the code window and select Toggle->Break on Unhandled Errors from the context menu. This should solve your problems.

Q: What is the purpose of the ITestContainer_RunTestCase method? Why can't the COMUnit framework execute the test method directly?

A: Good question! The ITestContainer_RunTestCase method is used to execute the test method specified by the supplied ITestCase object. Ideally this method would exist in the COMUnit framework and the framework would be able to execute the test method directly. However, it doesn't because of the fact that the test code is contained in an EXE Project -- not a DLL. In order to invoke CallByName or InvokeHook across component boundaries the component must support interface discovery by implementing IDispatch. However, as the test project is not a COM component, there is no opportunity for interface discovery. When instances of a TestContainer are passed to the COMUnit framework, they are cast to the ITestContainer interface. However, because there is no interface discovery, there is no way to discover the public test methods in the TestContainer instance. Bummer. It is possible to put your test code in a DLL circumventing this problem, but this creates an additional code maintainance burden. It's a tradeoff.

Q: Why does the ITestContainer_RunTestCase method have an error handler. Why can't this be handled in the COMUnit framework?

A: This issue is similar to the question above. If you choose to put your test code in an EXE Project, it is not a COM component. As a result, it cannot throw exceptions and have them handled by an external component. So the exceptions must be handled locally to the component. Once again, it is a tradeoff. If this is a problem, implement your test code in a DLL.

Q: What's the difference between InvokeHook and CallByName?

A: The main difference between these two methods is that InvokeHook is a more elegant implementation that won't mangle your exceptions if they occur in your test methods. CallByName is implemented in the VBA library which is referenced by default in your project. Whereas, InvokeHook is implemented in the TypeLib Info library which must be explicitly referenced. Pick which option is your preference. Or if you like neither, make a big Select Case statement to execute the supplied method name.

Q: When I run my test project I get a 'Subscript out of range' exception. What gives?

A: Well, in one of your TestContainers, the ITestContainer_TestCaseNames method is probably empty. Change it to return an empty array instead.

Page updated: 2002-09-16