[py-dev] using funcargs for setup/teardown
holger at merlinux.eu
Mon Oct 26 11:26:28 CET 2009
On Sun, Oct 25, 2009 at 14:00 +0000, Frederik Dohr wrote:
>> It contains many examples and also a reference for the API. I consider
>> splitting the two aspects.
> That's probably a good idea.
>> If py.test did some basic logging that shows which user code is
>> invoked when (e.g. test function, setup functions, funcarg
>> factories, plugin or conftest hooks ...) it would make such
>> help-examples smaller and more focused.
>> Below is a try at explaining funcargs from a "read-source" perspective.
> Unfortunately, I cannot relate to this - likely due to my overall
> ignorance when it comes to funcargs.
> 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 don't want to argue "simplicity" but let me state my perspective
and considerations - maybe they shed some light on why i consider the
funcargs approach more powerful: test functions are Python functions.
Python functions need certain objects to run. Why now use degraded
Python functions for tests, i.e. ones that never receives parameters?
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. It also means that setups for
different aspects, e.g. mocking a database and mocking a web service
intermingle in one setup area whereas funcarg factories allow to keep
such setup aspects totally separate and reuseable across the whole test suite.
> All of this is to say that I'm happy enough with this for setup and
> teardown*, but I'm probably the wrong person to comment on anything
> beyond that.
i disagree also here a bit - rather appreciate your feedback
More information about the Pytest-dev