azure-sdk-for-python
azure-sdk-for-python copied to clipboard
Azure
Added Cross partition query tests for sync and async APIs
Description:
- Current query (both sync and async) tests are running on single partition collections.
- Duplicated the same query tests to run on multiple partition collection for sync and async APIs.
- Fixed setup and cleanup process of tests to make sure tests can run in parallel without causing resource conflicts.
- Fixed some of the skipped tests and enabled them
- Fixed Cosmos CI to run on Emulator by default
![azure-pipelines[bot] avatar](https://avatars.githubusercontent.com/in/9426?v=4 "Published by a pub.dev verified publisher"){kind=small}
Still going through the files but figured I'd leave two comments on things I saw.
Firstly, I see that the use of the unittest package has been re-added to the SDK tests in several places - we had recently moved away from using that package since it was supposed to have issues with running async tests and most/all other Python SDKs are no longer using it in favor of the default pytest package and the test proxy that Core offers (that we purposely don't use since we don't want to run tests against recordings.) Here was the PR: https://github.com/Azure/azure-sdk-for-python/pull/32076 - I believe to be aligned with everyone else we should probably not re-add this package unless we absolutely need it for some reason.
Secondly, more of a nitpick, but I see in several files there is not a blank line at the end of the files - which I believe is a formatting rule that we try to use in all our SDKs (I believe even Java does the same).
So far so good with the actual changes though, and it does seem like the pipelines are all passing 👍 thanks Kushagra!
@simorenoh - thanks Simon, understood, however, unittest only had issues with running async tests because of python 3.7. Starting python 3.8 it can run both sync and async just fine. Currently I am using both unittest and pytest.
unittest is great for standard testing practices as it provides boiler plate code for setup, teardown, setupClass and tearDownClass whereas pytest is used for fixtures which are used across the whole test setup. In my opinion, pytest is more advanced and might be an overkill in some of the basic test setup.
Regarding new line at the end, I will add one.