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

[Victor Maryama]

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 <rpfannsc at 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 <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
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20191016/5c107ca7/attachment-0001.html>