[py-dev] using funcargs for setup/teardown

[Philippe Fremy]

holger krekel wrote:
> Hi Frederik!
>   
>> However, I've finally figured out why I'm having such a hard time  
>> warming up to funcargs: They go way beyond the minimalist simplicity  
>> that made me switch to py.test in the first place.
>> (I realize there's some Magic to py.test's internals, but that doesn't  
>> surface in the API.)
>>
>> Funcargs seem like a departure from this principle.
>> I understand that some situations demand such complexity, so I'm not  
>> arguing against funcargs in general - but for my part, I've managed to  
>> keep it simple so far.
>>     
I second Frederic here. I chose py.test because of the overall
simplicity of the framework when you use it. The
setup_module/setup_class/setup_method without any special magic other
than using function, class or method names starting with test is really
really nice. I am kind of worried because I could no longer find them in
the documentation. I eventually found them in the xUnit documentation
but that's not where I expected them. I vote for a return of this
documentation to the main py.test documentation, and moving funcarg
related documentation to an "advanced test setup" section.

funcarg seems to be a powerful tool, but really cumbersome to grok. I
find the magic trick on the naming with __myargument a bit cumbersome. I
would feel more comfortable with a syntax that mimic the setup/teardown
used for module, class and methods.

> This implies having to call magic methods for setting up objects in 
> global namespaces or 'self' attributes - which not only makes the test 
> harder to understand and refactor IMO. 

I do not agree here. If I have one class with 30 unit test methods, it's
easier to setup/teardown the test parameters in two methods for the
whole class than modifying 30 test methods to add funcargs arguments.

So, while I agree that funcargs certainly has potential, I think you
should not force it onto the user and should really stress the two ways
of setting up per class or per method parameters.

And it would be really nice to figure out a syntax for funcarg that is
more in the setup/teardown fashion.

I don't see much gain of using :

def pytest_funcarg__mysetup(request):
    return MySetup(request)

class TestClass:
    def test_function(self, mysetup):
        conn = mysetup.getsshconnection()
        # work with conn


instead of :

class TestClass:
    def setup_class( c ):
        c.mysetup = MySetup()

    def test_function(self):
        conn = c.mysetup.getsshconnection()
        # work with conn


The programming style is different, the second one is traditional OO and
will be familiar to anybody coming from C++, Java or other OO world. The
second one is playing more on the python capabilities. I don't find it
more readable.

One can argue about the advantage that each test function can take a
different parameter. While true, in my testing experience, I haven't
seen a pattern with many different tests taking many different
parameters. I usually have groups of 5 to 10 tests taking one kind of
parameter. If they need to take another kind of parameter, I will put
them in a different test class.

So, in my opinion, using funcargs for regular cases is a matter of style.

I do see a big value in funcargs for the parameterized tests. Running
the same test over and over with different parameter is a really nice
feature. I think you should stress it more in the documentation.

cheers,

Philippe