> 1) Do we want to use additional plugins? Yes. We should use the full-power of plugins now.
> 2) Do we want to use custom markers? Reply in a separate thread. >3) Do we want to use new assert statement? Reply in a separate thread > 4) Do we want to remove the inheritance from unittest.TestCase? Yes. After dropping support for Airflow 2.0, if possible. I would prefer to focus on working on new features for Airflow 2.0. > 5) Do we want to use class-less tests? No. Classes allow easy grouping of tests. Even if a file with one class now exists, a new one may appear in the future. > 6) Do we want to use pytest function instead of current? I feel good about the current functions. However, this is not a serious relationship and I can create a new friendship. > 7) Do we want to use monkeypatch fixture? No. I prefer unittest.mock > 8) Do we want to use the pytest fixtures? No. I prefer classic fixtures, if possible. Their syntax is much simpler and easier to understand. On Wed, Jan 1, 2020 at 8:10 PM Kamil Breguła <kamil.breg...@polidea.com> wrote: > Hello, > > > We have recently migrated to pytest. Code written according to the > standard library - unittest.TestCase is still compatible with pytest. > > > The AIP-21 document did not discuss the migration of current code to > new features, but only discussed the change of runner and benefits of > pytest over nosetets. > > Link: > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-27+Migrate+to+pytest > > > As far as I appreciate the many advantages of using this tool, but I am > not sure **whether, how or when we want to start using some features**. I > prefer to keep the current project conventions in many areas, but I still > love pytest. I think we should establish general conventions on writing > tests and recommended solutions to known problems. I prefer a pragmatic > approach, not just the use of features, because now we can use it. > Unfortunately, I do not see many benefits from new features. > > > I would not like the code to have many ways of expressing the same > solution. For the following reasons: > > > * it can introduce a lack of understanding among new contributors > > * facilitate the understanding and reading of code. > > * creates unnecessary discussion about the preferences of one way over the > other. Not related to changes. > > * forces an understanding of the complex syntax of some solutions. > > * encourages people to rewrite the code, which can generate unnecessary > work. > > > To establish a full convention, I have prepared a few questions: > > 1) Do we want to use additional plugins when there is no function in the > standard library e.g. flaky marker, forked marker? This is, in my opinion, > one of the big advantages of migrating to pytest. > > 2) Do we want to use custom markers? > > The discussion takes place in a separate thread: > > > https://lists.apache.org/thread.html/4538437c96f599766005ba7829d0bee1511debb4f53599e0d300a56f%40%3Cdev.airflow.apache.org%3E > > 3) Do we want to use new assert statement? > > > https://lists.apache.org/thread.html/08b64d3b084c865399f98f6c6f56235ce5329e843d97938e1a8045a5%40%3Cdev.airflow.apache.org%3E > > Based on the discussion with devlist, we want to delay migrations to the > new assert statement. > > 4) Do we want to remove inheritance from unittest.TestCase? > > 5) Do we want to use class-less tests? > > 6) Do we want to use pytest function instead of current? > > For example: > > Unittest.assertRaises vs pytest.raises > > parametrize vs pytest.mark.parametrize > > unittest.skip[If], vs pytest.mark.skip[If] > > 7) Do we want to use monkeypatch fixture? > > https://docs.pytest.org/en/latest/monkeypatch.html > > 8) Do we want to use the pytest fixtures? > > Do we want to migrate all code to pytest fixtures? > > We are currently using a different style of fixtures. Do we want to give > it up? > > https://docs.python.org/3/library/unittest.html#class-and-module-fixtures > > > It is worth asking to think about whether we do not want to change this > convention in the future e.g. after dropping support for 1.10.X. We can > also allow two conventions on a temporary basis, and then migrate to one at > a later time. For example, we want to migrate to the assert statement after > dropping support for 1.10 > > > I hope I found the main differences between the current convention and the > new convention. However, if you missed something, please continue to number. > > > Best regards, > > Kamil > > > >
