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
guideline an calling officially for "[LAZY CONSENSUS]" on it (and in
the meantime proceed with implementation :D.
J
On Fri, Jul 11, 2025 at 11:36 AM Kyungjun Lee <kyungjunlee...@gmail.com>
wrote:
> 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 <kyungjunlee...@gmail.com>님이 작성:
>
> > I want to lead this discussion!!!
> >
> > 2025년 7월 11일 (금) 오후 6:18, Jarek Potiuk <ja...@potiuk.com>님이 작성:
> >
> >> We just need a volunteer (or few) to drive it :D
> >>
> >> On Fri, Jul 11, 2025 at 11:15 AM Jarek Potiuk <ja...@potiuk.com> 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 + the "pytest-first" patterns. I
> >> think
> >> > it would be cool to indeed propose a "guideline" first and then
> possibly
> >> > even rewrite things and add some guardrails to flag non-pytest usages
> >> > automatically (pre-commit) - that is always the best to not only
> >> "agree" on
> >> > something but automate keeping that in-check.
> >> >
> >> > We could likely - again - use AI and run a small mini-project to
> convert
> >> > all our tests. I think if we write detailed-enough guideline, we can
> >> > literally prompt AI "rewrite the test code here following the
> guidelines
> >> > here".
> >> >
> >> > So what I see as an "outcome of a discussion" is:
> >> > * to collaboratively work on the guidelines
> >> > * make them both human and AI digestible
> >> > * add guardrails to not add old style in new files and to gradually
> mark
> >> > parts of the code as "done" when done
> >> > * run the "mini-project" to apply it consistently (and maybe as a
> >> > result iterate and correct and improve the guidelines)
> >> >
> >> > J.
> >> >
> >> >
> >> > On Fri, Jul 11, 2025 at 7:57 AM Amogh Desai <amoghdesai....@gmail.com
> >
> >> > wrote:
> >> >
> >> >> +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",
> >> >> task_id="pull_task",
> >> >> map_index=-1,
> >> >> ),
> >> >> )
> >> >> for x in mock_supervisor_comms.send.call_args_list
> >> >> )
> >> >>
> >> >>
> >> >> call_args_list is particularly useful in scenarios when you want to
> >> >> validate presence / absence of a call.
> >> >>
> >> >> Thanks & Regards,
> >> >> Amogh Desai
> >> >>
> >> >>
> >> >> On Thu, Jul 10, 2025 at 8:39 PM Kyungjun Lee <
> kyungjunlee...@gmail.com
> >> >
> >> >> wrote:
> >> >>
> >> >> > 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
> >> here,
> >> >> I’ve
> >> >> > come to realize that overusing assert can also be problematic. It’s
> >> >> been a
> >> >> > great reminder that we should be intentional about what we choose
> to
> >> >> assert
> >> >> > — making sure we’re testing what truly matters.
> >> >> >
> >> >> >
> >> >> > I’ll also follow up soon with an example snippet and a brief
> testing
> >> >> guide
> >> >> > to help clarify the discussion.
> >> >> >
> >> >> > 2025년 7월 10일 (목) 오후 11:49, Tzu-ping Chung <t...@astronomer.io.invalid
> >> >님이
> >> >> 작성:
> >> >> >
> >> >> > > 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 <gid....@gmail.com> wrote:
> >> >> > > >
> >> >> > > > 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 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 is arguably less
> >> readable. I
> >> >> > > offer another syntax.
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > from unittest.mock import call
> >> >> > > > >
> >> >> > > > > assert mock_http_run.mock_calls == [
> >> >> > > > > call(
> >> >> > > > > endpoint=f"api/v2/accounts/{expected_account_id}/",
> >> >> > > > > data=None,
> >> >> > > > > extra_options=None,
> >> >> > > > > )
> >> >> > > > > ]
> >> >> > > > > assert mock_paginate.mock_calls == []
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > To me, this is on par with assert_called_once_with et al. in
> >> >> terms of
> >> >> > > readability, and arguably better for test authors since you don’t
> >> >> need to
> >> >> > > remember the various function names anymore, but only
> 'mock_calls'
> >> and
> >> >> > the
> >> >> > > 'call' helper class.
> >> >> > > > >
> >> >> > > > > TP
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > > On Jul 9, 2025, at 23:28, Ferruzzi, Dennis
> >> >> > <fe...@amazon.com.INVALID>
> >> >> > > wrote:
> >> >> > > > > >
> >> >> > > > > > 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 for more documentation, but I'd have a slight
> >> >> preference
> >> >> > > towards keeping the existing structure.
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > > - ferruzzi
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > > ________________________________
> >> >> > > > > > From: Kyungjun Lee <ky...@gmail.com>
> >> >> > > > > > Sent: Tuesday, July 8, 2025 2:13 AM
> >> >> > > > > > To: dev@airflow.apache.org
> >> >> > > > > > Subject: RE: [EXT] [DISCUSS] Consistent test assertion
> style:
> >> >> > > pytest-native vs unittest-style
> >> >> > > > > >
> >> >> > > > > > CAUTION: This email originated from outside of the
> >> >> organization. Do
> >> >> > > not click links or open attachments unless you can confirm the
> >> sender
> >> >> and
> >> >> > > know the content is safe.
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > > AVERTISSEMENT: Ce courrier électronique provient d’un
> >> expéditeur
> >> >> > > externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce
> jointe
> >> si
> >> >> > vous
> >> >> > > ne pouvez pas confirmer l’identité de l’expéditeur et si vous
> >> n’êtes
> >> >> pas
> >> >> > > certain que le contenu ne présente aucun risque.
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > > 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 <am...@gmail.com>님이
> 작성:
> >> >> > > > > >
> >> >> > > > > >> 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 to
> >> >> > > > > >> test explicitly and assert
> >> >> > > > > >> on them.
> >> >> > > > > >>
> >> >> > > > > >>> This happens because the mock object is not properly
> >> >> recognized
> >> >> > as
> >> >> > > a mock
> >> >> > > > > >> instance at type-checking time, which might confuse some
> >> >> > > contributors,
> >> >> > > > > >> especially new ones relying on type hints or static
> analysis
> >> >> > tools.
> >> >> > > > > >>
> >> >> > > > > >> Regarding this, I'd say you can either cast mocks to their
> >> >> types
> >> >> > as
> >> >> > > one
> >> >> > > > > >> way:
> >> >> > > > > >> `mock_http_run: MagicMock = mock_http_run` -- give or
> take,
> >> or
> >> >> use
> >> >> > > > > >> `autospec` to make the mock reflect the signature of the
> >> >> object?
> >> >> > > Check out:
> >> >> > > > > >>
> >> >> https://docs.python.org/3/library/unittest.mock.html#autospeccing
> >> >> > > > > >>
> >> >> > > > > >> Thanks & Regards,
> >> >> > > > > >> Amogh Desai
> >> >> > > > > >>
> >> >> > > > > >>
> >> >> > > > > >> On Mon, Jul 7, 2025 at 6:13 PM Ash Berlin-Taylor <
> >> >> > as...@apache.org>
> >> >> > > wrote:
> >> >> > > > > >>
> >> >> > > > > >>> 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 is
> >> >> unique
> >> >> > to
> >> >> > > > > >> mocks.
> >> >> > > > > >>>
> >> >> > > > > >>>> On 7 Jul 2025, at 12:47, Kyungjun Lee <ky...@gmail.com>
> >> >> > > > > >> wrote:
> >> >> > > > > >>>>
> >> >> > > > > >>>> 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=["default_account", "explicit_account"],
> >> >> > > > > >>>> )
> >> >> > > > > >>>> @patch.object(DbtCloudHook, "run")
> >> >> > > > > >>>> @patch.object(DbtCloudHook, "_paginate")
> >> >> > > > > >>>> def test_get_account(self, mock_paginate, mock_http_run,
> >> >> > conn_id,
> >> >> > > > > >>>> account_id):
> >> >> > > > > >>>> hook = DbtCloudHook(conn_id)
> >> >> > > > > >>>> hook.get_account(account_id=account_id)
> >> >> > > > > >>>>
> >> >> > > > > >>>> assert hook.method == "GET"
> >> >> > > > > >>>>
> >> >> > > > > >>>> _account_id = account_id or DEFAULT_ACCOUNT_ID
> >> >> > > > > >>>> hook.run.assert_called_once_with(
> >> >> > > > > >>>> endpoint=f"api/v2/accounts/{_account_id}/", data=None,
> >> >> > > > > >>>> extra_options=None
> >> >> > > > > >>>> )
> >> >> > > > > >>>> hook._paginate.assert_not_called()
> >> >> > > > > >>>>
> >> >> > > > > >>>> ```
> >> >> > > > > >>>>
> >> >> > > > > >>>> My IDE shows a warning:
> >> >> > > > > >>>> Cannot find reference 'assert_called_once_with' in
> >> >> 'function'.
> >> >> > > > > >>>>
> >> >> > > > > >>>> This happens because the mock object is not properly
> >> >> recognized
> >> >> > > as a
> >> >> > > > > >> mock
> >> >> > > > > >>>> instance at type-checking time, which might confuse some
> >> >> > > contributors,
> >> >> > > > > >>>> especially new ones relying on type hints or static
> >> analysis
> >> >> > > tools.
> >> >> > > > > >>>>
> >> >> > > > > >>>> I realized that this aspect of mock handling might be
> >> missing
> >> >> > > from our
> >> >> > > > > >>>> previous discussions. I wanted to bring it up as part of
> >> the
> >> >> > > broader
> >> >> > > > > >>>> conversation about test styles—particularly how we
> balance
> >> >> > > IDE/tooling
> >> >> > > > > >>>> support with readability and style consistency.
> >> >> > > > > >>>>
> >> >> > > > > >>>> Curious to hear your thoughts on this!
> >> >> > > > > >>>>
> >> >> > > > > >>>> @ash @potiuk
> >> >> > > > > >>>>
> >> >> > > > > >>>> 2025년 7월 6일 (일) 오후 8:09, Kyungjun Lee <ky...@gmail.com
> >님이
> >> >> 작성:
> >> >> > > > > >>>>
> >> >> > > > > >>>>> 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.
> >> >> > > > > >>>>>
> >> >> > > > > >>>>> Thanks to your input, I was able to read more materials
> >> and
> >> >> > > broaden my
> >> >> > > > > >>>>> thinking on the topic. That said, my original focus was
> >> >> more on
> >> >> > > the
> >> >> > > > > >> idea
> >> >> > > > > >>>>> that sticking to plain assert statements lowers the
> entry
> >> >> > > barrier for
> >> >> > > > > >>> new
> >> >> > > > > >>>>> contributors—because they don’t have to learn multiple
> >> >> > assertion
> >> >> > > > > >> styles.
> >> >> > > > > >>>>>
> >> >> > > > > >>>>> Still, as @Potiuk mentioned, I’ll put more thought into
> >> >> making
> >> >> > > the
> >> >> > > > > >>> testing
> >> >> > > > > >>>>> guidelines clearer and more concrete—especially since
> >> that
> >> >> > helps
> >> >> > > > > >>> AI-based
> >> >> > > > > >>>>> tools as well 😄
> >> >> > > > > >>>>>
> >> >> > > > > >>>>> For reference, here’s one of the articles I read:
> >> >> > > > > >>>>>
> >> >> https://medium.com/@kentbeck_7670/test-desiderata-94150638a4b3
> >> >> > > > > >>>>>
> >> >> > > > > >>>>> Thank you to everyone who took part in this discussion.
> >> >> > > > > >>>>>
> >> >> > > > > >>>>> 2025년 7월 6일 (일) 오후 3:42, Ash Berlin-Taylor <
> >> >> as...@apache.org
> >> >> > >님이
> >> >> > > 작성:
> >> >> > > > > >>>>>
> >> >> > > > > >>>>>> 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 already rewrites those to have
> nicer
> >> >> error
> >> >> > > > > >>> messages,
> >> >> > > > > >>>>>> but the dedicated mock assert finding are much easier
> to
> >> >> read
> >> >> > > the
> >> >> > > > > >> code
> >> >> > > > > >>> and
> >> >> > > > > >>>>>> understand the intent to me, so I’i am for staying
> with
> >> the
> >> >> > > dedicated
> >> >> > > > > >>>>>> assert functions
> >> >> > > > > >>>>>>
> >> >> > > > > >>>>>> -ash
> >> >> > > > > >>>>>>
> >> >> > > > > >>>>>>> On 5 Jul 2025, at 13:30, Kyungjun Lee <
> ky...@gmail.com
> >> >
> >> >> > > > > >>> wrote:
> >> >> > > > > >>>>>>>
> >> >> > > > > >>>>>>> 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 <
> >> ja...@potiuk.com
> >> >> >님이
> >> >> > 작성:
> >> >> > > > > >>>>>>>
> >> >> > > > > >>>>>>>>> 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
> >> >> > > while
> >> >> > > > > >>> also
> >> >> > > > > >>>>>>>> fixing the mock order issue.
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>> "Sure! Since you asked ..." sounds like an AI bot.
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>>> That got me thinking — what do you think about
> >> adding a
> >> >> > > guideline
> >> >> > > > > >>>>>>>> document
> >> >> > > > > >>>>>>>> for writing tests, similar to how we have a coding
> >> style
> >> >> > > guide?
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>> Absolutely - we already have some "seed' of it
> >> "Writing
> >> >> > tests"
> >> >> > > > > >>>>>> chapter in
> >> >> > > > > >>>>>>>> contributing guideline, but we could definitely make
> >> it
> >> >> more
> >> >> > > > > >>> detailed.
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>
> >> >> > > > > >>>
> >> >> > > > > >>
> >> >> > >
> >> >> >
> >> >>
> >>
> https://github.com/apache/airflow/blob/main/contributing-docs/testing/unit_tests.rst#writing-unit-tests
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>> And - speaking of AI - this is becoming more and
> more
> >> >> > > important to
> >> >> > > > > >>>>>> describe
> >> >> > > > > >>>>>>>> any common rules we have and context - so that using
> >> >> Agentic
> >> >> > > AI
> >> >> > > > > >>> yields
> >> >> > > > > >>>>>>>> better results. Kaxil already added
> >> >> > > > > >>>>>>>>
> https://github.com/apache/airflow/blob/main/AGENTS.md
> >> >> which
> >> >> > > > > >>> describes
> >> >> > > > > >>>>>>>> context for coding agents lile Codex - and we could
> >> >> improve
> >> >> > > it and
> >> >> > > > > >>> link
> >> >> > > > > >>>>>>>> more docs from our repo if they get more of our
> agreed
> >> >> > > > > >> "conventions"
> >> >> > > > > >>> -
> >> >> > > > > >>>>>> then
> >> >> > > > > >>>>>>>> Agents would get it as context and their generated
> >> code
> >> >> > would
> >> >> > > be
> >> >> > > > > >>>>>> consistent
> >> >> > > > > >>>>>>>> with what we describe there.
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>> In a way - I think having a good documentation on
> >> >> processes,
> >> >> > > tools
> >> >> > > > > >>> and
> >> >> > > > > >>>>>>>> conventions was always something I've been after,
> but
> >> >> with
> >> >> > the
> >> >> > > > > >>> Agentic
> >> >> > > > > >>>>>>>> workflows it might significantly boost the quality
> of
> >> >> > > generated
> >> >> > > > > >> code
> >> >> > > > > >>>>>> if we
> >> >> > > > > >>>>>>>> have more of those conventions and guidelines
> >> described.
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>> So .... ABSOLUTELY ... the more we describe in
> there,
> >> the
> >> >> > > better.
> >> >> > > > > >> And
> >> >> > > > > >>>>>> we
> >> >> > > > > >>>>>>>> have no more excuse that "anyhow no-one reads it" -
> >> >> because
> >> >> > > the
> >> >> > > > > >>> coding
> >> >> > > > > >>>>>>>> agents WILL be reading it and acting accordingly.
> So I
> >> >> think
> >> >> > > this
> >> >> > > > > >> is
> >> >> > > > > >>> a
> >> >> > > > > >>>>>> very
> >> >> > > > > >>>>>>>> good investment to make.
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>> J.
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>>
> >> >> > > > > >>>>>>>>> On Sat, Jul 5, 2025 at 2:07 PM Kyungjun Lee <
> >> >> > > > > >>> kyungjunlee...@gmail.com
> >> >> > > > > >>>>>>>
> >> >> > > > > >>>>>>>>> wrote:
> >> >> > > > > >>>>>>>>>
> >> >> > > > > >>>>>>>>> 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, similar to how we have a coding
> >> style
> >> >> > > guide? It
> >> >> > > > > >>>>>> might
> >> >> > > > > >>>>>>>>> help ensure consistency across the Airflow codebase
> >> >> when it
> >> >> > > comes
> >> >> > > > > >> to
> >> >> > > > > >>>>>>>>> testing styles as well.
> >> >> > > > > >>>>>>>>>
> >> >> > > > > >>>>>>>>> 2025년 7월 5일 (토) 오후 8:52, Jarek Potiuk <
> >> ja...@potiuk.com
> >> >> >님이
> >> >> > > 작성:
> >> >> > > > > >>>>>>>>>
> >> >> > > > > >>>>>>>>>> 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 <
> >> >> > > ja...@potiuk.com>
> >> >> > > > > >>>>>> 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 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 - you see as if
> >> the
> >> >> call
> >> >> > > was
> >> >> > > > > >>>>>>>> actually
> >> >> > > > > >>>>>>>>>>> written down. Also this is quite a bit too many
> >> >> > assertions
> >> >> > > in
> >> >> > > > > >> the
> >> >> > > > > >>>>>>>>> second
> >> >> > > > > >>>>>>>>>>> case and it takes a lot of mental effort to
> >> understand
> >> >> > what
> >> >> > > > > >>> actually
> >> >> > > > > >>>>>>>> is
> >> >> > > > > >>>>>>>>>>> being asserted.
> >> >> > > > > >>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>> There is a "school" of writing unit tests that
> >> every
> >> >> test
> >> >> > > should
> >> >> > > > > >>>>>> have
> >> >> > > > > >>>>>>>>> ONE
> >> >> > > > > >>>>>>>>>>> assertion only. Always. I think it is a bit
> >> extreme,
> >> >> and
> >> >> > I
> >> >> > > do
> >> >> > > > > >> not
> >> >> > > > > >>>>>>>>> follow
> >> >> > > > > >>>>>>>>>> it
> >> >> > > > > >>>>>>>>>>> myself but I think it is also a kind of good
> >> >> direction to
> >> >> > > have
> >> >> > > > > >> ->
> >> >> > > > > >>>>>> the
> >> >> > > > > >>>>>>>>>> fewer
> >> >> > > > > >>>>>>>>>>> assertions you have in your test, the better (I
> >> >> think).
> >> >> > > > > >>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>> I think tests should be mostly optimized for
> >> easiness
> >> >> of
> >> >> > > reading
> >> >> > > > > >>> and
> >> >> > > > > >>>>>>>>>>> understanding what is being tested - and it's
> just
> >> not
> >> >> > > that easy
> >> >> > > > > >>> in
> >> >> > > > > >>>>>>>> the
> >> >> > > > > >>>>>>>>>>> second case.
> >> >> > > > > >>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>> J.
> >> >> > > > > >>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>> On Sat, Jul 5, 2025 at 1:39 PM Kyungjun Lee <
> >> >> > > > > >>>>>>>> kyungjunlee...@gmail.com>
> >> >> > > > > >>>>>>>>>>> wrote:
> >> >> > > > > >>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>> 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_CONN, None),
> >> >> (NO_ACCOUNT_ID_CONN,
> >> >> > > > > >>>>>>>>>> ACCOUNT_ID)],
> >> >> > > > > >>>>>>>>>>>> ids=["default_account", "explicit_account"],
> >> >> > > > > >>>>>>>>>>>> )
> >> >> > > > > >>>>>>>>>>>> @patch.object(DbtCloudHook, "run")
> >> >> > > > > >>>>>>>>>>>> @patch.object(DbtCloudHook, "_paginate")
> >> >> > > > > >>>>>>>>>>>> def test_get_account(self, mock_paginate,
> >> >> mock_http_run,
> >> >> > > > > >> conn_id,
> >> >> > > > > >>>>>>>>>>>> account_id):
> >> >> > > > > >>>>>>>>>>>> hook = DbtCloudHook(conn_id)
> >> >> > > > > >>>>>>>>>>>> hook.get_account(account_id=account_id)
> >> >> > > > > >>>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>> assert hook.method == "GET"
> >> >> > > > > >>>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>> expected_account_id = account_id or
> >> >> DEFAULT_ACCOUNT_ID
> >> >> > > > > >>>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>> assert mock_http_run.call_count == 1
> >> >> > > > > >>>>>>>>>>>> assert mock_http_run.call_args.args == ()
> >> >> > > > > >>>>>>>>>>>> assert mock_http_run.call_args.kwargs == {
> >> >> > > > > >>>>>>>>>>>> "endpoint":
> >> >> f"api/v2/accounts/{expected_account_id}/",
> >> >> > > > > >>>>>>>>>>>> "data": None,
> >> >> > > > > >>>>>>>>>>>> "extra_options": None,
> >> >> > > > > >>>>>>>>>>>> }
> >> >> > > > > >>>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>> assert mock_paginate.call_count == 0
> >> >> > > > > >>>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>> ```
> >> >> > > > > >>>>>>>>>>>> Why I chose this style:
> >> >> > > > > >>>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>> -
> >> >> > > > > >>>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>> *Mock verification using assert*: Instead of
> >> >> > > > > >>>>>>>>>>>> mock.assert_called_once_with(...), I used
> >> call_count
> >> >> and
> >> >> > > > > >>>>>>>> call_args.
> >> >> > > > > >>>>>>>>>>>> This
> >> >> > > > > >>>>>>>>>>>> approach aligns better with pytest’s idioms and
> >> >> produces
> >> >> > > > > >>> cleaner,
> >> >> > > > > >>>>>>>>>> more
> >> >> > > > > >>>>>>>>>>>> readable error messages when assertions fail.
> >> >> > > > > >>>>>>>>>>>> -
> >> >> > > > > >>>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>> *Explicit verification*: Using call_args.args
> and
> >> >> > > > > >>>>>>>> call_args.kwargs
> >> >> > > > > >>>>>>>>>>>> makes
> >> >> > > > > >>>>>>>>>>>> the test behavior very explicit, which helps
> with
> >> >> > > debugging
> >> >> > > > > >> and
> >> >> > > > > >>>>>>>>>>>> understanding the exact calls made.
> >> >> > > > > >>>>>>>>>>>> -
> >> >> > > > > >>>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>> *Decorator order matching argument order*: As
> >> @patch
> >> >> > > > > >> decorators
> >> >> > > > > >>>>>>>>> apply
> >> >> > > > > >>>>>>>>>>>> from the bottom up, the argument order has been
> >> >> > corrected
> >> >> > > to
> >> >> > > > > >>>>>>>> match
> >> >> > > > > >>>>>>>>> (
> >> >> > > > > >>>>>>>>>>>> mock_paginate first, then mock_http_run).
> >> >> > > > > >>>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>> Let me know if you'd like to follow a slightly
> >> >> different
> >> >> > > > > >>> convention
> >> >> > > > > >>>>>>>> —
> >> >> > > > > >>>>>>>>>>>> happy
> >> >> > > > > >>>>>>>>>>>> to adjust!
> >> >> > > > > >>>>>>>>>>>>
> >> >> > > > > >>>>>>>>>>>> I was lu
> >> >> > > > [message truncated...]
> >> >> > >
> >> >> > >
> >> ---------------------------------------------------------------------
> >> >> > > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
> >> >> > > For additional commands, e-mail: dev-h...@airflow.apache.org
> >> >> > >
> >> >> > >
> >> >> >
> >> >>
> >> >
> >>
> >
>
