TextTest is about testing at the system level, and it is expected that you are trying to run your system in as similar a way as possible to how it is used in practice. It is, however, more important to have maintainable, repeatable tests that are free of global side effects. Sometimes it is necessary to disable some part of the system, or fake some behaviour that cannot easily be triggered for real in a repeatable way. This is referred to as “mocking out” a subsystem for testing purposes.

TextTest has built-in integration with CaptureMock, which was indeed part of TextTest up until the 3.20 release and was designed to work with it. CaptureMock can help you capture and replay interactions with command-line programs, Python modules and functions, and also synchronous plain-text messaging over a network. See its own documentation on this site for more details, particularly here for how to use it from TextTest.

Sometimes capturing what something does isn't sufficient and you need finer-grained control over the behaviour. In this case you can make use of "executable" and "importable" test data.

When TextTest creates the sandbox directory on running the test, and populates it with test data, it also makes sure to insert that directory at the start of the PATH, PYTHONPATH and CLASSPATH variables. That makes it possible to provide executable programs that will be run instead of their real versions via the normal test data mechanism (“link_test_path”). Then you just need to place such executable test data in the appropriate place in the permanent test structure, just as you would with more passive test data.

Likewise, you can provide a Python module or a Java class, which will then be imported instead of the real version at the appropriate moment.

For Python programs, though, there is an alternative, which is usually preferable. This is to provide a file called "testcustomize.py". The idea of this is to be similar to Python's "sitecustomize.py", i.e. to provide some Python code that will be called on interpreter startup just for that test or test suites (it can be provided anywhere in the hierarchy, like anything else).

Suitable "monkey-patching" can then be done to control the behaviour of certain classes. The advantages of this is that it's easy to change the behaviour of several modules from a single location, it's easier to "monkey patch" individual functions rather than entire modules, and because it isn't dependent on PYTHONPATH, it works to manipulate also the behaviour of builtin modules.

Naturally, there are mocking frameworks in most programming languages that give more control still. These however are often written primarily with unit testing in mind and tend to assume that you are coding your tests against an API. As such they are not always easy to use from fully black-box tests with TextTest where test code does not really feature. By writing some kind of wrapper script around your program it is usually possible to make use of them in some way, though.