[TIP] 5 lines of code equals 30+ lines of single test
ned at nedbatchelder.com
Wed Jul 18 07:18:06 PDT 2012
On 7/18/2012 12:58 AM, John Wong wrote:
> Hi guys,
> Here is a simple function.
> def readfile(*args, **kwargs):
> local = kwargs.get('local', os.getcwd())
> filename = args
> f_path = os.path.join(local, filename)
> with open(f_path, 'r') as f:
> return f.read()
> Now here is just ONE case of the readfile test code. For readabilty, I
> will put in pastebin.com <http://pastebin.com>
> I am verifying how many times X Y C dependencies are called and what
> parameters are passed to them. I think these are necessary to check
> (what if one of the dependency functions called with the wrong variable).
You definitely don't have to mock os.path.join. You don't care that it
called that function, you care that it opened the right path, and you
already have a check for that. You're over-testing the implementation
of the function. Focus on the externally-observable behavior.
If you are checking call_args_list, then .called or .call_count is
redundant, so remove those lines from the test.
BTW: the function itself is a bit odd. Why use **kwargs if you only use
one keyword, and *args if you only use the first element?
> But is this really the nature of unittest? I've read many tests code
> and they all seen to be 5-20 lines..... I faint when I am reading my
> test code.............. SIGH
> I have some 10 lines function and it took 50 lines to test! Let alone
> for each of these functions, I need to write a a few tests for each
> branch case...
> So if there are 10 functions, each 5 lines, I can end up with 1000
> lines of test code....
> Last question, I find my patching is really really long and
> inconvince. How should I patch (say they all come from os package)?
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the testing-in-python