How to supply stdin, files and environment variable inputs to Python unit tests?

All three situations you've described are where you need to specifically go out of your way to ensure you are using loose coupling in your design.

Do you really need to unit test Python's raw_input method? The open method? os.environ.get? No.

You need to set up your design so that you can substitute other ways of retrieving that input. Then, during your unit tests, you'll throw in a stub of some sort that doesn't actually call raw_input or open.

For instance, your normal code might be something like:

import osdef say_hello(input_func):    name = input_func()    return "Hello " + namedef prompt_for_name():    return raw_input("What is your name? ")print say_hello(prompt_for_name)# Normally would pass in methods, but lambdas can be used for brevityprint say_hello(lambda: open("a.txt").readline())print say_hello(lambda: os.environ.get("USER"))

The session looks like:

What is your name? somebodyHello somebodyHello [some text]Hello mark

Then your test will be like:

def test_say_hello():    output = say_hello(lambda: "test")    assert(output == "Hello test")

Keep in mind that you should not have to test a language's IO facilities (unless you're the one designing the language, which is a different situation entirely).

If you are tied to using raw_input (or any other specific input source), I'm a big proponent of the mock library. Given the code that Mark Rushakoff used in his example:

def say_hello():    name = raw_input("What is your name? ")    return "Hello " + name

Your test code could use mock:

import mockdef test_say_hello():     with mock.patch('__builtin__.raw_input', return_value='dbw'):         assert say_hello() == 'Hello dbw'     with mock.patch('__builtin__.raw_input', side_effect=['dbw', 'uki']):         assert say_hello() == 'Hello dbw'         assert say_hello() == 'Hello uki'

These assertions would pass. Note that side_effect returns the elements of the list in order. It can do so much more! I'd recommend checking out the documentation.

If you can get away without using an external process, do so.

However, there are situations where this is complicated, and you really want to use process, e.g., you want to test the command line interface of a C executable.

User input

Use subprocess.Popen as in:

process = subprocess.Popen(    command,    shell  = False,    stdin  = subprocess.PIPE,    stdout = subprocess.PIPE,    stderr = subprocess.PIPE,    universal_newlines = True)stdout, stderr = process.communicate("the user input\nline 2")exit_status = process.wait()

There is no difference between taking input from a user and taking it from a pipe for input done with methods like raw_input or sys.stdin.read().

Files

• Create a temporary directory and create the files you want to read from in there on your test setUp methods:

  tdir = tempfile.mkdtemp(    prefix = 'filetest_', )fpath = os.path.join(tdir,'filename')fp = open(fpath, 'w')fp.write("contents")fp.close()

• Do the file reading in the tests.

• Remove the temp dir afterwards.

  shutil.rmtree(tdir)

• It is quite complicated reading from files, and most programs can read either from files or from STDIN (e.g. with fileinput). So, if what you want to test is what happens when a certain content is input, and your program accepts STDIN, just use Popen to test the program.

Environment variables

• Set the environment variables with os.environ["THE_VAR"] = "the_val"
• Unset them with del os.environ["THE_VAR"]
• os.environ = {'a':'b'} does not work
• Then call subprocess.Popen. The environment is inherited from the calling process.

Template Code

I have a module on my github that tests STDOUT, STDERR and the exit status given STDIN, command line arguments and enviroment. Also, check the tests for that module under the "tests" dir. There must be much better modules out there for this, so take mine just for learning purposes.