Hi Philippe, could you maybe send your mail again as plain text? i had problems interpreting the html version although i probably got the gist of it.
thanks, holger On Tue, Nov 10, 2009 at 14:34 +0100, Philippe Fremy wrote: > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > <html> > <head> > <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> > </head> > <body bgcolor="#ffffff" text="#000000"> > holger krekel wrote: > <blockquote cite="mid:20091104175718.gv29...@trillke.net" type="cite"> > <pre wrap="">Hi Philippe, > > On Wed, Oct 28, 2009 at 08:09 +0100, Philippe Fremy wrote: > </pre> > <blockquote type="cite"> > <pre wrap="">holger krekel wrote: > </pre> > <blockquote type="cite"> > <pre wrap="">Hi Frederik! > > </pre> > <blockquote type="cite"> > <pre wrap="">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. > > </pre> > </blockquote> > </blockquote> > <pre wrap="">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. > </pre> > </blockquote> > <pre wrap=""><!----> > I am worried that newcomers will be confused then. But i see > the point of "unhiding" the xUnit documentation. > </pre> > </blockquote> > You could present the two approaches in the documentation and > explaining what are the differences.<br> > <br> > The simplicity of the setup/teardown model is really a strong asset for > testing. It makes the test code architecture understandable by people > not familiar with py.test . The same can not be said for the funcarg > mechanism...<br> > <br> > <blockquote cite="mid:20091104175718.gv29...@trillke.net" type="cite"> > <blockquote type="cite"> > <pre wrap="">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. > </pre> > </blockquote> > <pre wrap=""><!----> > It would be easy to also allow explicit registration for factories ala: > > def pytest_configure(config): > config.add_funcarg_factory(name, factoryfunc) > > but at the time i choose "convention over configuration" and the > "__" because Django also uses a similar way to encode values into > a function name. > </pre> > </blockquote> > I can understand that, but it does not "speak" to people that are not > famliar with this approach. By using this convention, my impression is > that you are leaving behind the people who are just used to functions, > classes and methods.<br> > <br> > <br> > <blockquote cite="mid:20091104175718.gv29...@trillke.net" type="cite"> > <blockquote type="cite"> > <blockquote type="cite"> > <pre wrap="">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. > </pre> > </blockquote> > <pre wrap="">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. > </pre> > </blockquote> > <pre wrap=""><!----> > agreed, i am considering introducing a new hook: > > def pytest_pyfunc_setup(request): > request.cached_setup(setupfunc, teardownfunc, scope="directory") > > and this hook would be called for each python test function. Here > we call the cached_setup helper to help us manage setup/teardown scopes. > (see <a class="moz-txt-link-freetext" > href="http://tinyurl.com/yfw82l5";>http://tinyurl.com/yfw82l5</a> for request > object attributes > which you could pass into your setup/teardown func) > > It would also mean you could write down: > > class TestGroup: > parameter = 3 > def test_method(self): > assert self.parametrized_obj ... > > and implement a pytest_pyfunc_setup() to set a "self.someobj" > according to the class-specified parameter. > > Would this make sense to you? > </pre> > </blockquote> > Honestly, I am not sure I get it all. Can you sketch full examples ?<br> > <br> > By the way, is it possible to dynamically update the py.test namespace > ? There is the initial hook py_test_namespace() but it's only called > once. A py.test.update_namespace() would be welcome in my case.<br> > <br> > <blockquote cite="mid:20091104175718.gv29...@trillke.net" type="cite"> > <blockquote type="cite"> > <pre wrap="">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. > </pre> > </blockquote> > <pre wrap=""><!----> > ok, I'll see to work on the docs a bit. > > </pre> > <blockquote type="cite"> > <pre wrap="">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. > </pre> > </blockquote> > <pre wrap=""><!----> > If you have setup_module + setup_class + setup_method (+ subclassing!) > layers of setup and teardown, things get a bit harder to understand. > In >3000 test projects i know off this led to complexity and > refactoring difficulties. > </pre> > </blockquote> > I haven't reached for > 3000 test cases, so I can not comment on > that. But for small projects like the one I am working with (around a > few hundreds tests), the setup/teardown works very well.<br> > <blockquote cite="mid:20091104175718.gv29...@trillke.net" type="cite"> > <blockquote type="cite"> > <pre wrap="">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. > </pre> > </blockquote> > <pre wrap=""><!----> > These days i sometimes group tests by feature rather than by > setup-parameters. > E.g. i put two unit-tests and one functional test into a "TestFeature" class. > </pre> > </blockquote> > Then you need a different setup depending on which test you are running > indeed. But you can already do that by discriminating on the method > argument of the setup_method(), no ?<br> > <blockquote cite="mid:20091104175718.gv29...@trillke.net" type="cite"> > <blockquote type="cite"> > <pre wrap="">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. > </pre> > </blockquote> > <pre wrap=""><!----> > makes sense. thanks a lot for your feedback! > > best, > holger > > </pre> > </blockquote> > <br> > </body> > </html> > > > _______________________________________________ > py-dev mailing list > py-dev@codespeak.net > http://codespeak.net/mailman/listinfo/py-dev -- _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
