Since we need to tackle CI stability I would like to bump this one if
anyone wants to say something :) I am full speed ahead with implementing
those.
*Proposed Breeze changes:*
>
>- `./breeze` by default will start only the main 'airflow-testing'
>image. This way no huge resource usage
>
> It's hard to guess how many test sets are required and how many
> extra lines of "marker code" are needed for each category and how the Venn
> diagrams work out.
I believe (but that's mostly gut feeling) that significant majority of our
tests
will fall into "no-marker" camp. @Tomasz Urbaszek
The link to
https://docs.pytest.org/en/latest/example/markers.html#custom-marker-and-command-line-option-to-control-test-runs
helps
to clarify some of the customization required to add CLI options that
select test sets based on markers. +1 for a common default with *no
marker*. (It's hard to
>
> If I understand correctly, using `pytest -k` might be less work and more
> generalized than a swag of custom makers, unless it entails a lot of
> re-naming things. The work to add markers might be easier if they can be
> applied to entire classes of tests, although what I've mostly seen with
If I understand correctly, using `pytest -k` might be less work and more
generalized than a swag of custom makers, unless it entails a lot of
re-naming things. The work to add markers might be easier if they can be
applied to entire classes of tests, although what I've mostly seen with
`pytest`
The suggestion of using -k flag is really interesting. It will require a
lot of changes but adding
marks will require the same effort. However, I think that using a marker
is more explicit and
easier to spot.
Regarding "slow test" marker, I did a quick calculation of tests execution
times
Consider all the options for filtering tests:
- http://doc.pytest.org/en/latest/example/markers.html
The `pytest -k` filters are very useful. Provide guidelines on how to name
things so that `pytest -k` can be used to filter categories of tests. Use
markers for tests that might be the
+1 for integrations and backends, it's a good start ;)
T.
On Fri, Dec 27, 2019 at 12:16 PM Jarek Potiuk
wrote:
> Since I am going to start working on it soon - I'd love to get some
> opinions :).
>
> J.
>
> On Mon, Dec 23, 2019 at 11:13 AM Jarek Potiuk
> wrote:
>
> > I have a concrete
Since I am going to start working on it soon - I'd love to get some
opinions :).
J.
On Mon, Dec 23, 2019 at 11:13 AM Jarek Potiuk
wrote:
> I have a concrete proposal that we can start with. It's not a final set of
> markers we might want to have but one that we can start with and make an
>
I have a concrete proposal that we can start with. It's not a final set of
markers we might want to have but one that we can start with and make an
immediate use of.
I would like to adapt our tests to be immediately usable in Breeze (and
tied with it) and follow this approach:
*Proposed Breeze
It is worth adding that we currently use test marking in the project. For
this purpose, we use the prefix "_system.py" in the file name.
Unit tests:
https://github.com/apache/airflow/blob/master/tests/operators/test_gcs_to_gcs.py
System tests:
I am all-in for markers.
I think we should start with small set of useful markers, which should have
a useful purpose from the beginning and implement them first - to learn how
useful they are (before we decide on full set of markers).
Otherwise maintaining those markers will become a fruitless
Hi everyone,
Since we run our tests using pytest we are able to use test markers [1].
Using them will give
use some useful things:
- additional information of test type (ex. when used for system test)
- easy way to select test by types (ex. pytest -v -m "not system")
- way to split our test suite
13 matches
Mail list logo
