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 os
def say_hello(input_func):
name = input_func()
return "Hello " + name
def 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 brevity
print say_hello(lambda: open("a.txt").readline())
print say_hello(lambda: os.environ.get("USER"))
The session looks like:
What is your name? somebody
Hello somebody
Hello [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).
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…