[TIP] 5 lines of code equals 30+ lines of single test

[Ronny Pfannschmidt]

On 07/18/2012 08:03 AM, John Wong wrote:
> Thanks Ronny. But isn't the whole point of using Mock is to patch out
> dependencies code? Meaning we should only leave out the code within a
> single unit (all the functions called should be patched out, and
> assigned a return_value / side_effect if applicable)?
but there is much less point in mocking things a pure function uses

>
> In another word, if we split as you said, then we should still patch out
> readfile_makepath, shouldn't we?

yes, still we have gone from dozens of points to patch out
to one point for one function

the point isn't to get rid of Mock,
but to make the code easyer/simpler to test

and to minimize the size of the actual unittests


>
> John
>
> On Wed, Jul 18, 2012 at 1:22 AM, Ronny Pfannschmidt
> <Ronny.Pfannschmidt at gmx.de <mailto:Ronny.Pfannschmidt at gmx.de>> wrote:
>
>     you might want to design for testability to keep test complexity low
>
>     for example you can split it up as
>
>     def readfile_makepath(name, local=None, get_default=os.getcwd):
>        if local is None:
>          local = get_default()
>        return os.path.join(local, name)
>
>     def readfile(name, local=None):
>        f_path = readfile_makepath(name, local)
>        with open(f_path) as fp:
>          return fp.read()
>
>     * all of path construction can be tested witout patching now
>     * for readfile you only need to test that the args
>        are passed to _makepath and open is called with the result
>     * for paranoya you can add a test
>        to assert that get_default is os.getcwd
>
>     -- Ronny
>
>
>     On 07/18/2012 06:58 AM, John Wong wrote:
>
>         Hi guys,
>
>         Here is a simple function.
>
>         def readfile(*args, **kwargs):
>               local = kwargs.get('local', os.getcwd())
>               filename = args[0]
>               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> <http://pastebin.com>
>         http://pastebin.com/P45uc2TV
>
>         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).
>
>         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)?
>
>         Thanks.
>         John
>
>
>         _________________________________________________
>         testing-in-python mailing list
>         testing-in-python at lists.idyll.__org
>         <mailto:testing-in-python at lists.idyll.org>
>         http://lists.idyll.org/__listinfo/testing-in-python
>         <http://lists.idyll.org/listinfo/testing-in-python>
>
>
>