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
