[pytest-dev] [proposal] global and per item data stashes

Ronny Pfannschmidt rpfannsc at redhat.com
Wed Oct 16 09:42:01 EDT 2019


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 <rpfannsc at redhat.com>
wrote:

>
>
> On Wed, 16 Oct 2019 at 01:23, Bruno Oliveira <nicoddemus at 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 <rpfannsc at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20191016/da0c536e/attachment.html>


More information about the pytest-dev mailing list