Support
FAQ
Troubleshooting
Troubleshooting
-
vbUnit doesn't run any tests
I can run the TestVBUnitFramework project, but I get some failures.
When I double-click on a result, vbUnit doesn't find the correct line in the source-code.
When I run tests and there is a syntax error that prevents the program under test from compiling, the offending code is not highlighted in the code window.
The vbUnit Add-In seems to interfere with my other Add-Ins.
When I run tests, I get a run-time error that says "Run-time error '-2147220501 (800403eb)': Assertion Failed"
When running the compiled test, I get the error message: "TestRunner ERROR (run Tests) : Automation error. The object invoked has disconnected from its clients."
After upgrading from an earlier beta version, I get "Compile error : can't find project or library" when trying to compile my test suite.
When I click on "File / New Project", I don' see the option for a "vbUnit TestDll"
When I double-click on a result in the vbUnit Add-In window, all the files of my project get opened. How can I stop this?
vbUnit3.04.07 doesn't work if the logged-on user does not have administrative rights.
vbUnit doesn't run any tests
First of all, please go through the basic usage examples and try to run the TestVBUnitFramework suite exactly as described. If that really doesn't work, maybe there is a problem.System Requirements
vbUnit is certified for Visual Basic 6.0 with Visual Studio Service Pack 5 installed. If you try to run vbUnit on machines with earlier versions of VB, or on machines without VB, it may not work correctly.It has been tested on the following operating systems with the indicated minimum level of service packs: Windows NT 4.0 (SP6), Windows 2000 (SP2), and Windows XP (SP1).
Localization
If you have a localized (i.e. non-English) version of VB, you may need to adjust the control strings for starting and stopping the debugger. The default for starting the debugger is "^{F5}" (for "CTRL - F5").The default for stopping the debugger is "%RE" (for "ALT - Run / End"). If your menu entry to stop the debugger is for example "Ausführen / Beenden", then the control string for stopping the debugger needs to be "%AB".
Registry corruption
If you had earlier beta versions of vbUnit3 and didn't unregister them before installing a newer version, your registry may be corrupted. To find out if this is the case, first run unregister.bat in the \bin directory of your current vbUnit installation. Then use OLE View (a tool that comes with Visual Studio), open "Object Classes / All Objects" and check that you don't have any remaining vbUnit3 objects.If you do, you need to reinstall the old version (with setup.bat), and then uninstall it again (with unregister.bat). After this procedure, check your registry with OLE View again. If you still have vbUnit3 objects, you could use Regedit to manually clean your registry. Please ask someone who has done this before though, since I won't describe it in more detail. There are also some registry cleaning tools to be found on the web. And in the future, uninstall old versions properly before installing a new version.
Other problems
If your registry is ok and you really cannot run the vbUnitTestSuite project, even after reading the instructions and following them, please send us an and describe the problem in as much detail as possible.
I can run the TestVBUnitFramework project, but I get some failures.
If your operating system does not use the English locale setting, the method TestVBUnit.TestAssert will probably fail. This is expected. If your version of VB is not English, some other tests may fail as well.However, if some tests fail that are not related to non-English locales, please and let us know the details.
When I double-click on a result, vbUnit doesn't find the correct line in the source-code.
The code line that corresponds to a failed assertion is found by matching the type of the assertion (e.g. LongsEqual or StringsEqual) and the assertion message.To make this work, the assertion message must be a literal string (e.g. "msg1"), not an expression (such as "msg" & i).
Further, the assertion message must be unique within the search scope. Hence, if the failed assertion is located in the actual TestMethod, the assertion message must be unique within this method. If the failed assertion is located outside of the TestMethod, the assertion message should be unique within the file or project. You should study the class "TestHighlightCode" in the "TestVBUnitFramework" project for examples of all these cases.
When I run tests and there is a syntax error that prevents the program under test from compiling, the offending code is not highlighted in the code window.
Visual Basic does highlight the offending code, but this highlighting is not displayed because the vbUnit Add-In window is still in focus. To see VBs highlighting after a failed compile, scroll the code window up or down one line.
The vbUnit Add-In seems to interfere with my other Add-Ins.
It has been reported that CodeSmart 2001 has some problems while tests are run from the vbUnit Add-In window. This happens because vbUnit sets the current directory to the path of the compiled test suite. This could also affect other VB Add-Ins. If you suspect that vbUnit is causing your other Add-Ins to malfunction, uncheck "set current directory to module path" in vbUnit Options / TestRunner and see if your problem persists. The only consequence of unchecking that option is that your tests should no longer use relative file references, since they will now have a different base directory depending on whether they are being run in compiled or in debug mode. This should no longer happen in version 3.05.00 and higher, but final confirmation of the fix is still outstanding.
When I run tests, I get a run-time error that says "Run-time error '-2147220501 (800403eb)': Assertion Failed"
This is by design. Since a failed assertion is treated like an error, vbUnit will raise a custom error with Err.Raise to exit the current TestMethod when encountering a failed assertion. If you don't want to see the run-time error, set your error trapping mode to "Break on Unhandled Errors", as described in the usage instructions.
When running the compiled test, I get the error message: "TestRunner ERROR (run Tests) : Automation error. The object invoked has disconnected from its clients."
You are probably compiling the test as an "ActiveX EXE". Change the project type of your test project to "ActiveX DLL".
After upgrading from an earlier beta version, I get "Compile error : can't find project or library" when trying to compile my test suite.
Some of the beta versions are not binary compatible with each other. After upgrading, go to the Project / References dialog, remove the reference to "MISSING: vbUnit3 - Unit Test Framework", close the references dialog, open it again, and then select the reference to vbunit3 again, which should now not be missing anymore.
When I click on "File / New Project", I don' see the option for a "vbUnit TestDll"
The project and class templates for vbUnit are not installed. You can do this manually: Copy everything in the vbUnit3\Templates folder into [VB6 Path]\Template\Projects. Also, copy the *.cls files into [VB6 Path]\Template\Classes. By default, VB6 is installed at C:\Program Files\Microsoft Visual Studio\VB98.You should open the templates in the target folder and edit them to point to the correct location of RunVBUnit.exe, unless you installed vbUnit into "c:\vbunit3".
When I double-click on a result in the vbUnit Add-In window, all the files of my project get opened. How can I stop this?
This will no longer happen in version 3.05.00 and higher.You are using assertions without unique assertion messages. When you double-click on a result in the Add-In window, vbUnit tries to find the corresponding line in your source code where the assertion was made. This is done by matching the assertion type (e.g. LongsEqual or StringsEqual), and the assertion message. If a corresponding match cannot be found in the method where the assertion came from, the search is extended to the whole file, and then to all files in this project. And to search a file, it must be opened in the IDE.
You can do either of two things: Reduce the search scope of vbUnit in the vbUnit Options dialog ("Jump to failed assertion"), or you could use unique assertion messages that are literal strings.
vbUnit3.04.07 doesn't work if the logged-on user does not have administrative rights.
This is true. In version 3.04.09 and higher, vbUnit3 can be run from a normal user account in WinNT 4.0. However, to run it in Win2000, the logged-on user must be at least a Power User (this seems to be true for using VB in general).