Python Testing – How to Automate Testing of a C Program Using Python

I'd use the first option; embed the bash script in a multi-line string in the Python script, then write that out and use the subprocess module to run the script:

import tempfile
import subprocess

script_one = '''\
echo "Hello world!"
echo "This is a bash script. :-)"
'''

def run_script(script):
    with tempfile.NamedTemporaryFile() as scriptfile:
        scriptfile.write(script)
        scriptfile.flush()
        subprocess.call(['/bin/bash', scriptfile.name])

run_script(script_one)

The run_script() function takes a bash script source, writes it to a temporary file, executes it, and automatically cleans up the temporary file when done.

Demo:

$ python /tmp/scripttest.py 
Hello world!
This is a bash script. :-)

Python decorators are of no help here; there is no point in looking at those; decorators are simply Python functions that get to wrap other Python functions.

If the script is large, you could try compressing it with zlib, base64 encode it, then embed that into the Python script file; using .decode('base64') and passing the result to the zlib module first gives you a decompressed string again. The ZLIB compression reduces the size but results in binary data, always a little harder to embed without having to deal with proper escaping and line lengths. The Base64 encoding turns the binary data into multi-line ASCII-safe data again, albeit at the price of 25% more bytes:

>>> import zlib
>>> zlib.compress(script_one).encode('base64')
'eJxLTc7IV1DySM3JyVcozy/KSVFU4koFi4VkZBYrAFGiQlJicYZCcXJRZkGJnoKVrqYSFwDnexDe\n'
>>> print """script_one = '''\\\n{}'''""".format(_)
script_one = '''\
eJxLTc7IV1DySM3JyVcozy/KSVFU4koFi4VkZBYrAFGiQlJicYZCcXJRZkGJnoKVrqYSFwDnexDe
'''

Note that for this short script sample, this increased the size, from 54 characters to 77, but for longer scripts you should see a decent size reduction.

Decompression is then as simple as zlib.decompress(script_one.decode('base64'))

If there is not a good reason to not do so, I would definitely advocate a spin on option 3. As @jonsharp mentions, breaking up your utility into clean units of functionality is a good way to ensure testability. Even the smallest scripts can eventually morph into a much larger program and making sure that you have an extensible API sooner rather than later will alleviate much headache down the road.

The way I'd approach this is:

1. Break up your code into logical methods with clean and clear I/O
2. Add unit tests. Having them is never a bad thing.
3. Rather than using if __name__ == '__main__', create a main() (or similar) method containing your entry point
4. Use setuptool's setup() function to define the script entry point in your setup.py file.

For example:

from setuptools import setup
setup(
    name='mypackage',
    version='0.1',
    entry_points={
        'console_scripts': [ 'myscript = mypackage.mymodule:main' ],
    }
)

Now, not only is all of your code (including main()) is easily unit testable, but you can still have your console entry point once you've done a python setup.py install|develop.

Any validation I do using, say, ArgumentParser.add_mutually_exclusive_group will not apply when my tool is run as a library instead of a command line script.

Depending on how your API is designed, you may need to add some extra validation to input parameters, but that should likely be there to prevent unexpected input anyways.

Edit: The only time I would use generally use subprocess is when I'm calling into a non-Python application or another Python script that I don't own or have the time to refactor, but the latter only being as a last resort. Most well-written Python utilities will expose both command line utilities and internal API.