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 <weilee...@gmail.com> 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 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-ping Chung <t...@astronomer.io.INVALID>
> 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 <ferru...@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 <kyungjunlee...@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 <amoghdesai....@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 <a...@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 <kyungjunlee...@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 <kyungjunlee...@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 <a...@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 <kyungjunlee...@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 lucky to have the chance to explain this while fixing a
> >>>>>>>>> related
> >>>>>>>>>>> bug.
> >>>>>>>>>>>>> You can refer to the changes in this PR:
> >>>>>>>>>>>>> https://github.com/apache/airflow/pull/52905
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2025년 7월 5일 (토) 오후 8:09, Jarek Potiuk <ja...@potiuk.com>님이
> 작성:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Just post how you think the test should be written :)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Sat, Jul 5, 2025 at 1:08 PM Jarek Potiuk <
> ja...@potiuk.com
> >>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I already mentioned it in slack - but how would you propose
> >>> to
> >>>>>>>>>>> rewrite
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>> "mixed" case to be more consistent ?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Sat, Jul 5, 2025 at 12:47 PM Kyungjun Lee <
> >>>>>>>>>>>>> kyungjunlee...@gmail.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> While reviewing and contributing to Airflow tests, I’ve
> >>>> noticed
> >>>>>>>>>> an
> >>>>>>>>>>>>>>>> inconsistency in how assertions are written. Some tests
> use
> >>>>>>>>>>>>>>>> `unittest`-style assertions like
> >>>>>>>>> `mock.assert_called_once_with`,
> >>>>>>>>>>>>> while
> >>>>>>>>>>>>>>>> others use plain `assert` statements in the `pytest`
> style.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Here's an example of a test using the mixed style:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ```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_http_run, mock_paginate,
> >>>>>>>>> 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()
> >>>>>>>>>>>>>>>> ```
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> In IDEs and type-checkers (like PyCharm or MyPy), this
> >>>>>>>>> sometimes
> >>>>>>>>>>>>> causes
> >>>>>>>>>>>>>>>> weak warnings
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ```
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Cannot find reference 'assert_called_once_with' in
> >>> 'function'
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ```
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> This could confuse newcomers or contributors unfamiliar
> with
> >>>>>>>>>>> mocking
> >>>>>>>>>>>>>>>> behavior or type limitations in dynamic typing.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> To improve clarity and accessibility for
> >>>>>>>>> contributors—especially
> >>>>>>>>>>>>> those
> >>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>> to the project—I’d like to propose *moving toward
> consistent
> >>>>>>>>> use
> >>>>>>>>>> of
> >>>>>>>>>>>>>> plain
> >>>>>>>>>>>>>>>> assert statements* for test validations wherever possible.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *Proposed Benefits*:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Easier onboarding for first-time contributors
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Better IDE support and fewer confusing warnings
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> More consistent and readable test style across the project
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I'd love to hear your thoughts on whether this direction
> >>> makes
> >>>>>>>>>>> sense
> >>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>> the project. If agreed, I’d also be happy to help align
> >>>>>>>>> existing
> >>>>>>>>>>>>> tests
> >>>>>>>>>>>>>>>> gradually.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>>>>> Kyungjun Lee
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
> >>>>>>> For additional commands, e-mail: dev-h...@airflow.apache.org
> >>>>>>>
> >>>>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
> >>>> For additional commands, e-mail: dev-h...@airflow.apache.org
> >>>>
> >>>>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
> > For additional commands, e-mail: dev-h...@airflow.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
> For additional commands, e-mail: dev-h...@airflow.apache.org
>
>
