>
>
> Judicious use of:
>
> # pylint: disable=do-not-use-asserts
>
> ^^ helps with interim use of pytest `assert`
>
>
Yeah. That will work. But then you would have to leave it in the code until
everything is converted. We already have a nice mechanism we use with
pylint_todo.txt which we could
Judicious use of:
# pylint: disable=do-not-use-asserts
^^ helps with interim use of pytest `assert`
On Wed, Jan 1, 2020 at 10:39 AM Kamil Breguła
wrote:
> Hello,
>
> As I mentioned earlier, I would prefer to maintain one convention for the
> project. The migration of the unittest assertions
I thought that thread was closed already :)
I would prefer that we just stick to the original question: *"I think we
should gradually switch to using asserts in our tests. WDYT?" * rather than
expand it and add more general questions (they are discussed in a separate
thread).
>From what I
I have an additional question and my reply:
Do we want to allow the use of new conventions for new tests?
No. I prefer keep one convention in the project.
Do we want to force the use of new conventions for new tests?
No. I prefer keep one convention in the project.
Do we want to allow mixed
Hello,
As I mentioned earlier, I would prefer to maintain one convention for the
project. The migration of the unittest assertions to the assert statement
can be done automatically, At the same time, it will limit discussions on
individual PRs.
I think Tomek supports my opinion:
Done. Closing the thread for now.
On Wed, Dec 18, 2019 at 6:21 PM Jarek Potiuk
wrote:
> Fully Agree ! I will do it then if no-one objects!
>
> On Wed, Dec 18, 2019 at 5:39 PM Tomasz Urbaszek <
> tomasz.urbas...@polidea.com> wrote:
>
>> I agree that global implementation of asserts should happen
Fully Agree ! I will do it then if no-one objects!
On Wed, Dec 18, 2019 at 5:39 PM Tomasz Urbaszek
wrote:
> I agree that global implementation of asserts should happen after 2.0. But
> in the meantime it seems reasonable to decided on using asserts in the
> future and enforce that all new,
I agree that global implementation of asserts should happen after 2.0. But in
the meantime it seems reasonable to decided on using asserts in the future and
enforce that all new, not-conflicting tests should be written in pytest way,
thus eliminating number of future changes.
Also, after
>
>
> but I'm not
> sure which option is the best. Should we use pytest or unittest method?
>
Yeah. This is the question that started the whole thread. So far only
enthusiastic "yes" for the pythonic "asserts" as far as I can see.
Anyone has some preference for the unittest ones ?
>
> On Wed,
Hello,
Some statistics:
$ grep -R -i 'assert ' tests/ | wc -l
151
$ grep -R -i 'self.assert' tests/ | wc -l
5445
So <3% of tests use native assertions. As for me, it is worth improving the
project convention so that all tests are written in one style, but I'm not
sure which option is
Yes I think I agree with that. We should now focus on new features and
improvements for the Users, now that we have done enough to improve it for
developers.
On Wed, Dec 18, 2019 at 1:34 PM Kamil Breguła
wrote:
> Hello,
>
>
> "I'd like to hold off on something as large-scale as
Hello,
"I'd like to hold off on something as large-scale as unittest2pytest until
2.0 is out/until we no longer have to backport changes to the v1-10-*
branches." ~Ash Berlin-Taylor
I would also prefer to focus on working on new features for Airflow 2.0
instead of improving the developer
Big yes to asserts in pytest!
On Tue, Dec 10, 2019 at 12:50 AM Michał Słowikowski <
michal.slowikow...@polidea.com> wrote:
> I like this idea, and such assertion looks very promising.
>
> assert "maximum recursion" in str(excinfo.value)
>
> Have a nice day!
>
>
> On Mon, Dec 9, 2019 at 6:16 PM
I like this idea, and such assertion looks very promising.
assert "maximum recursion" in str(excinfo.value)
Have a nice day!
On Mon, Dec 9, 2019 at 6:16 PM Tomasz Urbaszek
wrote:
> It's definitely worth a try! I even mentioned this in AIP-27. But I think
> this script does not change SetUp /
It's definitely worth a try! I even mentioned this in AIP-27. But I think
this script does not change SetUp / TearDown to an appropriate fixture.
T.
On Mon, Dec 9, 2019 at 6:03 PM Jarek Potiuk
wrote:
> Well. I think (as discussed with Kamil) maybe even convert the tests
> automatically.
>
>
Well. I think (as discussed with Kamil) maybe even convert the tests
automatically.
How about we try: https://github.com/pytest-dev/unittest2pytest
J.
On Mon, Dec 9, 2019 at 5:48 PM Tomasz Urbaszek
wrote:
> I agree. Should we encourage people to use asserts when adding new tests?
>
> T.
>
>
I agree. Should we encourage people to use asserts when adding new tests?
T.
On Mon, Dec 9, 2019 at 4:35 PM Kaxil Naik wrote:
> Yup, we should.
>
> On Mon, Dec 9, 2019 at 3:20 PM Ash Berlin-Taylor wrote:
>
> > Absolutely, and I don't think any of the concers about it in run-time
> code
> >
Yup, we should.
On Mon, Dec 9, 2019 at 3:20 PM Ash Berlin-Taylor wrote:
> Absolutely, and I don't think any of the concers about it in run-time code
> apply! Plus it is the way pytest recommends, and I think we get nicer
> failure messages using assert-style too?
>
> -a
>
> On 9 December 2019
Absolutely, and I don't think any of the concers about it in run-time code
apply! Plus it is the way pytest recommends, and I think we get nicer failure
messages using assert-style too?
-a
On 9 December 2019 15:06:07 GMT, Jarek Potiuk wrote:
>Hello everyone.
>
>So asserts are now banned from
Hello everyone.
So asserts are now banned from our main code. However with the recent
introduction of pytest we now have a chance to switch to using the standard
asserts instead of deriving from TestCase class and using assertSomething()
methods.
I find it much more readable and nice and pytest
20 matches
Mail list logo
