Thanks Kamil for raising this issue! I think we can split this migration in many simple steps but the moment of "chaos" how we do things is unavoidable. But AIP-21 (contrib -> core) created some confusion too. But I think we are doing fine with it.
When should we migrate? I dunno, I would like to do this asap. It will add some more confusion but it will end at some point. But if we postpone it to 2.0, we will finish one "chaos" (AIP-21) and start another one, then there could be a feeling that we are always in chaos. But this one touches only contributors, not users - that's a big difference. > 1) Do we want to use additional plugins? Yes. > 2) Do we want to use custom markers? Yes. >3) Do we want to use new assert statement? Yes. > 4) Do we want to remove the inheritance from unittest.TestCase? Yes. I think this can be done in two phases: I) use assert II) use pytest fixtures > 5) Do we want to use class-less tests? Yes if it's a single test per file or tests "cannot be grouped" (utils, helpers, etc). > 6) Do we want to use pytest function instead of current? I do not understand this point, can you explain? > 7) Do we want to use monkeypatch fixture? No. I too prefer unittest.mock > 8) Do we want to use the pytest fixtures? I am in favor of getting rid of unittest.TestCase and using pytest fixtures. In my opinion pytest fixtures are easier to read and thus limiting possibility of "forgetting something in teardown". Moreover, pytest fixtures are modular and reusable, can be defined in conftests (many) and used with different scopes (module, function, class). T. On Wed, Jan 1, 2020 at 8:14 PM Kamil Breguła <kamil.breg...@polidea.com> wrote: > > 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 > > > > > > > > >
