I had the opportunity to apply TP's suggestions and a version of my
suggestion in practice
when fixing brittle tests in providers today.
Practical example from: https://github.com/apache/airflow/pull/53747:
I replaced this fragile pattern:
*log_info_call = info_log_call.mock_calls[4]log_value =
Yeah. Good Point Ash.
Pytest already rewrites a lot of assertions to make them look "better" - so
hopefully those pytest-specific ones will be "nice". Also - if they won't
- I know there are quite a few plugins that "beautify" the output of such
asserts even more - including rich coloring etc. so
Please include what the pytest output looks like in a failure case to in any
proposal.
> On 11 Jul 2025, at 11:02, Jarek Potiuk wrote:
>
> It **looks** like we are close to consensus on that one. I think a good
> idea would be to create an outline proposal summarizing what we are going
> to hav
The downside to `assert not any(` is that you don’t get very nice
diagnostic/errors message when it fails — you don’t see the list of calls, you
just see something like “generator” instead
> On 11 Jul 2025, at 06:55, Amogh Desai wrote:
>
> +1 to TP's proposal too.
>
> It's easy to read and al
It **looks** like we are close to consensus on that one. I think a good
idea would be to create an outline proposal summarizing what we are going
to have finally, ask people for comments if anything has anything against
it, and if we do not see any "no' - create a PR with more details in the
guidel
Should we start by drafting the document first, or should we ask the
community through a vote whether it’s okay to create the guideline?
2025년 7월 11일 (금) 오후 6:31, Kyungjun Lee 님이 작성:
> I want to lead this discussion!!!
>
> 2025년 7월 11일 (금) 오후 6:18, Jarek Potiuk 님이 작성:
>
>> We just need a volu
I want to lead this discussion!!!
2025년 7월 11일 (금) 오후 6:18, Jarek Potiuk 님이 작성:
> We just need a volunteer (or few) to drive it :D
>
> On Fri, Jul 11, 2025 at 11:15 AM Jarek Potiuk wrote:
>
> > Yeah. I like it and the discussion :) - it's so cool to see so many
> > people taking part and leadin
We just need a volunteer (or few) to drive it :D
On Fri, Jul 11, 2025 at 11:15 AM Jarek Potiuk wrote:
> Yeah. I like it and the discussion :) - it's so cool to see so many
> people taking part and leading the discussion. The Airflow community is
> awesome.
>
> I think it's nice with pytest-mock
Yeah. I like it and the discussion :) - it's so cool to see so many people
taking part and leading the discussion. The Airflow community is awesome.
I think it's nice with pytest-mock + the "pytest-first" patterns. I think
it would be cool to indeed propose a "guideline" first and then possibly
e
Yes, `call` is supported, alongside other names from `unittest.mock`. In
some cases, like with `spy`, they not only mirror but also extend the
existing functionality. Ref:
https://pytest-mock.readthedocs.io/en/latest/usage.html
On 2025/07/10 14:47:30 Tzu-ping Chung wrote:
> Does pytest-mock have a
+1 to TP's proposal too.
It's easy to read and also stands out better.
We have a few places in the task-sdk tests where we also have done patterns
like:
assert not any(
x
== mock.call(
msg=GetXCom(
key="key",
dag_id="test_dag",
run_id="test_run
Thank you all — I really appreciate how many people have joined the
discussion.
I also like the approach that Tzu-ping Chung suggested. This really isn’t
an easy topic. At first, I thought it would be best to use only plain assert
statements, but after reading through the different perspectives he
+1 on TP's proposal, it reads well and stands out more than the
`.assert_called_...`. I'll try to use it in the future
On 2025/07/10 14:47:30 Tzu-ping Chung wrote:
> Does pytest-mock have an equivalent for call()? I agree for mocking in
> general we should consider replacing plain decorators and
Does pytest-mock have an equivalent for call()? I agree for mocking in general
we should consider replacing plain decorators and context managers with the
mocker fixture. This probably deserves its own discussion thread.
--
Sent from my iPhone
> On 10 Jul 2025, at 14:37, Dev-iL wrote:
>
> O
One tiny comment regarding TP's suggestion - IMHO it's better to avoid
`unittest.mock` in favor of the equivalent `mocker` fixture provided by
`pytest-mock`.
On 2025/07/10 06:30:22 Tzu-ping Chung wrote:
> Personally I dislike things like assert_called_once_with etc. since
they are easy to miss
Agreed - the proposal from TP looks much better. I did not know you could
do that. And it feels more consistent.
On Thu, Jul 10, 2025 at 2:22 PM Wei Lee wrote:
> I like what TP proposed. Even the original pytest style fits my taste
> better. The unittest style bugs me when I first contributed to
I like what TP proposed. Even the original pytest style fits my taste better.
The unittest style bugs me when I first contributed to Airflow. It’s already
way better than it used to be. But, I would love to see it move more towards a
pytest style.
Best,
Wei
> On Jul 10, 2025, at 2:30 PM, Tzu-p
Personally I dislike things like assert_called_once_with etc. since they are
easy to miss when you scan a test to see what they are trying to check. An
'assert' keyword stands out (it’s always the first word in the line),
especially with syntax highlighting.
I do agree the proposed Pytest style
I'm a bit late to the party, and really only reiterating what has already been
said, but of the two examples (original and your rewrite, I prefer the
original. I think as a general rule, we tend to use the assert_called_once,
etc with mocks butt he asserts with non-mocked variables.
I am all f
Thank you Ash and Amogh Desai for your insights and explanations.
The information you shared has been incredibly helpful and is contributing
a lot to my growth.
2025년 7월 8일 (화) 오후 2:54, Amogh Desai 님이 작성:
> Agreed, I personally also find the current way to be easier to read and in
> most
> cases
Agreed, I personally also find the current way to be easier to read and in
most
cases we want to assert if "something" was called, irrespective of the
order it was
called in. So the dedicated function based way works well for me.
If I want to test a order, I'd rather call parts of code that I want
def test_get_account(self, mock_paginate: Mock, mock_http_run: Mocj, conn_id,
account_id):
Might fix that? IDEs in general do not cope well with purest tests, and are
missing context on what most of the variables are, be it parameterised values
or fixture values, so this isn’t a problem that i
I'd like to follow up on our previous discussion about pytest-native vs
unittest-style assertions.
While working on the following test case:
```python
@pytest.mark.parametrize(
argnames="conn_id, account_id",
argvalues=[(ACCOUNT_ID_CONN, None), (NO_ACCOUNT_ID_CONN, ACCOUNT_ID)],
ids=
Thank you @Potiuk for pointing out the intent behind the “one assert per
test” principle, and @ash for highlighting how using dedicated mock assert
functions can make the code easier to read and understand. These were
perspectives I hadn’t fully considered, and I really appreciate you sharing
them.
I personally find the dedicated functions way easier to read the intent behind,
it’s one function/statement vs 3. More so when you don’t care about the order
of calls, just that something was called (where to do this manually we’d need
to reimplement the helper function)
Additionally pytest alr
I’ve learned a lot of things I didn’t know before.
Thank you so much for all your help — I really appreciate it.
I’ll get started on this right away!
2025년 7월 5일 (토) 오후 9:18, Jarek Potiuk 님이 작성:
> > Haha ... I'm curious — which part sounded like ChatGPT style?
> English isn't my first language, s
> Haha ... I'm curious — which part sounded like ChatGPT style?
English isn't my first language, so I did get a little help from it.
That whole paragraph :) .
>> Sure! Since you asked for how the test *should* be written, I took the
opportunity to clean it up using a more pytest-native style whil
Haha ... I'm curious — which part sounded like ChatGPT style?
English isn't my first language, so I did get a little help from it.
But thank you — I actually learned something new from your comment!
That got me thinking — what do you think about adding a guideline document
for writing tests, simil
But of course - i'd love to hear what others think - it's not a "very
strong" opinion.
On Sat, Jul 5, 2025 at 1:48 PM Jarek Potiuk wrote:
> Cool. That's what I wanted to see.
>
> By the way - not that there's anything wrong - but was the answer written
> by AI initially ? The first paragraph loo
Cool. That's what I wanted to see.
By the way - not that there's anything wrong - but was the answer written
by AI initially ? The first paragraph looks suspiciously like Chat GPT
answer :D ?
Comment from my side: I personally prefer the original style. It's more
concise and it is easier to read
Sure! Since you asked for how the test *should* be written, I took the
opportunity to clean it up using a more pytest-native style while also
fixing the mock order issue.
Here’s the updated test:
```python
@pytest.mark.parametrize(
argnames="conn_id, account_id",
argvalues=[(ACCOUNT_ID_C
31 matches
Mail list logo
