When this happens, while the tests will continue to run, they may not be testing the Chrome Frame instance you expect them to. To avoid this, always run the tests as admin.

chrome_frame_unittests.exe

This contains the unit tests for Chrome Frame. It can be run stand-alone and runs quite quickly. These tests run on the try servers.

How to run

1. Open some.sln and build chrome_frame\chrome_frame_unittests
2. Run chrome_frame_unittests.exe from the build folder.

chrome_frame_reliability_tests.exe

This is the test binary run on chromebot as part of the automated reliability tests. It is little more than a page cycler for IE running chrome frame. You can run it locally if you like, as with chrome_frame_tests.exe it registers CF at startup so needs to be run as admin.

chrome_frame_reliability_tests do not run on the try servers.

How to run

1. Open some.sln and build chrome_frame\chrome_frame_reliability_tests
2. Run chrome_frame_reliability_tests.exe from the build fold as admin (see above).

chrome_frame_net_tests.exe

This test is similar to Chrome’s net_unittests, it exercises Chrome-initiated network requests when run through the Chrome Frame network stack, i.e. when run serving network requests via IE over the automation interface, see e.g. (URLRequestAutomationJob). These tests need to be run as admin, since they also register Chrome Frame at startup.

This test works by setting up, in the test process, an environment that is as close as possible to that used by Chrome’s net tests except driven via a fake ExternalTab that emulates Chrome’s startup. Once setup, the tests run in a similar fashion to Chrome’s net tests, except that url requests are handled by Chrome Frame running in an IE instance over the automation interface.

Given that CF’s net tests attempt to start up pieces of Chrome outside of the norm (ie. outside of chrome.exe), it is fairly sensitive to new inter-module dependencies or invalid assumptions about startup order of different Chrome components. Most of the time when these tests break, they are being tickled by bad assumptions about startup order (code that assumes and doesn’t check that some subsystem of Chrome is initialized).

If debugging chrome_frame_net_tests, note that the entry point lives in src\chrome_frame\test\fake_external_tab.cc.

chrome_frame_net_tests run on the try servers.

Before anything else, be aware that running a component=shared_library build on another machine is a tricky affair. If you don't want to worry about getting the right version of the CRT on your test machine (hint: if you don't know what the CRT is, follow the advice to come after the close parens right here:), it's much simpler to use the component=static_library build.

Running some of Chrome Frame's tests from a different location than the build folder in the source tree can be annoying. For example, like Chrome's net tests, CF's net tests makes a number of assumptions about the directory structure it lives in. To ease running on a VM, the indomitable joi@ put together a poor man's trybot script that copies all the needed files to a given directory. Running this script from a mounted share that contains your build output directory on a VM is a common use case.

The script can be found at src/chrome_frame/test/poor_mans_trybot.bat. Sample use case from a virtual PC vm:

In addition, if you build a version of Chrome Frame that dynamically links the MSVCRT (aka the component build) then you may get a SxS error. SxS errors are really annoying to work around. You can work around them by:

where <VERSION> is the version number of the MSVCRT you linked against. Note that this may be different from the one included with your copy of MSVC, as many of these can live on a Windows system. To figure out which version your app expects, you can check the Application log in the Event Viewer (type "Event Viewer in the Win7 start menu) to discover the missing version. Then you have to go and find that version on your system and copy the three DLLs listed above into the Microsoft.VC90.DebugCRT directory.