The executed script is determined using the Request-Object. However, in some cases such as unit testing, there is no real request. As a result, the current executed script and especially it's path is the one of the script being executed by PHP.
This is not a problem until you include (only include, you even don't have to use it) components using for example CAssetManager (basically everything resorting to the request in order to get the path, I just blundered upon CAssetManager).
Bootstrap for instance is an extension using CAssetManager in it's initialization.
CAssetManager and every other class determining the path using the request should make use of an extra abstraction layer.
CAssetManager is designed to be used in Web environment. When it is not used so, you are responsible to customize the request object so that it can provide correct information.
You should be able to load very class inherent to the Yii base in any environment. Those classes are included in startup routines of all the other stuff, so if they don't work, they screw everything up. If they are no designed to handle non web-requests - then they should just pack it in (silent fail).
It's not an option to use request-hacks for each third-library. If it's not a web request, the class should just not interfere.
Another option is to define suitable environments for the different components, so they are only loaded if they're starting in a supported environment. I'm currently made a shift with that, but a general approach would be welcome.