Hi Victor, i took a initial look and i believe the tooling can intersect
a "stash/storage" would be used for the live part, and its tear-down could transfer the harvest details to a more compact/permanent storage/location/bubble them up. at work we are currently working on a service that stores/tracks test results/logs/selenium screen-shots for test execution, i marked it down as a research target for integration with pytest-harvest - Ronny On Wed, 16 Oct 2019 at 16:27, Victor Maryama <victor.mary...@gmail.com> wrote: > 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 > -- 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
