Hi guys! I am no expert, but maybe is this something that could replace or intersect with the functionality provided by https://smarie.github.io/python-pytest-harvest/ (fixture_store and results_bag fixtures)? And maybe the code that is saving fixture and test context information like in allure-pytest.
Although probably it would require the stashes not to be torn down, in opposition to the original Ronny's idea. Le mer. 16 oct. 2019 à 15:42, Ronny Pfannschmidt <rpfan...@redhat.com> a écrit : > a little side note as i was just having a little discussion about this > with a native speaker, > the word stash isn`t quite fitting the concept - the name scoped_storage > came to mind, > we might need to iterate on the concept name a bit to get to something > that makes deeper sense > > - Ronny > > On Wed, 16 Oct 2019 at 09:45, Ronny Pfannschmidt <rpfan...@redhat.com> > wrote: > >> >> >> On Wed, 16 Oct 2019 at 01:23, Bruno Oliveira <nicodde...@gmail.com> >> wrote: >> >>> Hi Ronny, >>> >>> As you have shared this before in chat, at first glance it sounds like a >>> good idea! >>> >>> Some questions that we can probably elaborate on once we have something >>> more concrete to discuss: >>> >>> 1. You say "each stash would be a context manager", but it is not clear >>> to me how this would work in practice, as most uses today that need to >>> decorate the object need to do it across multiple function calls (for >>> example, creating an object in `pytest_configure` and storing it in a >>> stash, only to retrieve the data later in another hook). Can you provide >>> examples to clarify this? >>> >> the value returned from get_stash would be the value the entering of the >> context manager yielded >> this also means that for a item or a class there may be multiple stashes >> over a test-run, as each stash would have been entered in a different >> lifecycles >> >> >> >>> >>> 2. If we are to use the "stash" for fixtures, we need a way to specify >>> stashes whose other lifetimes than function and session, like class, module >>> and package. Any idea how this would look like? >>> >> those stashes would just be modelled on the belonging nodes, so fixtures >> for session, stashed on session, fixtures for class, stashed on class and >> so on >> >> >> >>> >>> Other than that, where do you want to go from here? Keep the discussion >>> here in the mailing list, move it to the issue tracker, or somewhere else? >>> >> i'd like some more iteration on the basics, then perhaps a quick video >> conference to solidify the thinking, >> then set up a github project. >> >> -- Ronny >> >> >> >>> >>> Cheers, >>> Bruno. >>> >>> >>> On Tue, Oct 15, 2019 at 10:03 AM Ronny Pfannschmidt <rpfan...@redhat.com> >>> wrote: >>> >>>> Problem: for the storage of helper objects that either tackle certain >>>> global tracking details or that track information over the testprotocol >>>> lifecycle of test items, we use monkeypatchs and generally just munge >>>> around in either the pytest config object or item objects. >>>> >>>> I would like to propose a new API putting those details into >>>> consideration. >>>> >>>> >>>> >>>> config.get_stash(owner, type=pytest.NamespaceStash) # valid over the >>>> pytest session lifetime >>>> item.get_stash(owner, type=pytest.NamespaceStash) # valid across the >>>> run-test protocol cycle of item >>>> >>>> Each stash would be a context manager and construction would get >>>> access to both item and config. >>>> >>>> This would for example enable to express the junit xml logger object >>>> and configuration as >>>> >>>> `config.get_stash(__name__, JunitXMlTracker)` >>>> >>>> Just as it would allow other plugin to store node lifecycle related >>>> details within the node using a well known mechanism >>>> >>>> Incidentally this would also be a good fit for the fixture system and >>>> setup-state in general to store information. >>>> >>>> The basic assumption being that only the stashes of the items that are >>>> currently active are valid, and other stashes are torn down, >>>> then fixtures as well as the fixture request would nicely fit that >>>> storage mechanism, and would also generalize across the node tree from >>>> session down to individual items. >>>> >>>> (considering the layout, it might be sensible to even replace >>>> config.get_stash with something >>>> like session.get_stash) >>>> >>>> The idea is still rather fuzzy in my head and i would love to di either >>>> text based brainstorming on it, or a actual video call. >>>> >>>> -- Ronny >>>> >>>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, >>>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>>> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, >>>> Eric Shander >>>> >>>> _______________________________________________ >>>> pytest-dev mailing list >>>> pytest-dev@python.org >>>> https://mail.python.org/mailman/listinfo/pytest-dev >>>> >>> >> >> -- >> >> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, >> Commercial register: Amtsgericht Muenchen, HRB 153243, >> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, >> Eric Shander >> >> > > -- > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, > Eric Shander > > _______________________________________________ > pytest-dev mailing list > pytest-dev@python.org > https://mail.python.org/mailman/listinfo/pytest-dev >
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
