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
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
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
On Wed, 16 Oct 2019 at 01:23, Bruno Oliveira 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
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
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
