You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/dev/tests-advanced.md
+33-10Lines changed: 33 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,15 +3,17 @@ This guide covers advanced testing scenarios for Azure SDK for Python libraries.
3
3
4
4
## Table of contents
5
5
6
-
-[Mixin classes](#test-mixin-classes)
6
+
-[Mixin classes](#mixin-classes)
7
7
-[Pre-test setup](#pre-test-setup)
8
8
-[xunit-style setup](#xunit-style-setup)
9
9
-[Fixture setup](#fixture-setup)
10
+
-[Use HTTPS test proxy endpoint](#use-https-test-proxy-endpoint)
10
11
11
12
## Mixin classes
12
13
Many of our test suites use a base/mixin class to consolidate shared test logic. Mixin classes can define instance attributes to handle environment variables, make complex assertions, and more. By inheriting from these mixins, test classes can then share this logic throughout multiple files.
13
14
14
-
For example, in the Tables test suite there is a `_shared` directory containing two of these mixin classes: a [sync version](https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/tables/azure-data-tables/tests/_shared/testcase.py) and an [async version](https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/tables/azure-data-tables/tests/_shared/asynctestcase.py).
15
+
For example, in the Tables test suite there is a `_shared` directory containing two of these mixin classes: a
16
+
[sync version][mixin_sync] and an [async version][mixin_async].
15
17
16
18
```python
17
19
classTableTestCase(object):
@@ -86,8 +88,7 @@ Tests will often use shared resources that make sense to set up before tests exe
86
88
approaches for this kind of setup, with each having benefits and drawbacks.
87
89
88
90
### xunit-style setup
89
-
Pytest has documentation describing this setup style: https://docs.pytest.org/en/latest/how-to/xunit_setup.html. For
90
-
example:
91
+
Pytest has [documentation][xunit_setup] describing this setup style. For example:
91
92
92
93
```python
93
94
from devtools_testutils.azure_recorded_testcase import get_credential
@@ -115,8 +116,8 @@ instance attributes on the class. You can still set attributes on the test class
115
116
module-level utilities can be used in place of instance attributes, as shown in the example above.
116
117
117
118
### Fixture setup
118
-
Pytest has documentation explaining how to implement and use fixtures:
119
-
https://docs.pytest.org/en/latest/how-to/fixtures.html. For example, in a library's `conftest.py`:
119
+
Pytest has [documentation][fixtures] explaining how to implement and use fixtures. For example, in a library's
120
+
`conftest.py`:
120
121
121
122
```python
122
123
from devtools_testutils.azure_recorded_testcase import get_credential
@@ -141,14 +142,36 @@ class TestService(AzureRecordedTestCase):
141
142
By requesting a fixture from the test class, the fixture will execute before any tests in the class do. Fixtures are the
142
143
preferred solution from pytest's perspective and offer a great deal of modular functionality.
143
144
144
-
As shown in the example above, the
145
-
[`yield`](https://docs.pytest.org/latest/how-to/fixtures.html#yield-fixtures-recommended) command will defer to test
146
-
execution -- after tests finish running, the fixture code after `yield` will execute. This enables the use of a fixture
147
-
for both setup and teardown.
145
+
As shown in the example above, the [`yield`][fixture_yield] command will defer to test execution -- after tests finish
146
+
running, the fixture code after `yield` will execute. This enables the use of a fixture for both setup and teardown.
148
147
149
148
However, fixtures in this context have similar drawbacks to the `setup_class` method described in
150
149
[xunit-style setup](#xunit-style-setup). Since their scope is outside of the test class, test class instance utilities
151
150
can't be accessed and class state can't be modified.
152
151
153
152
By convention, fixtures should be defined in a library's `tests/conftest.py` file. This will provide access to the
154
153
fixture across test files, and the fixture can be requested without having to manually import it.
154
+
155
+
## Use HTTPS test proxy endpoint
156
+
157
+
By default, the test proxy is reached at `http://localhost:5000`. Service requests are ultimately made as usual with a
158
+
secure connection, but some libraries may require that the immediate proxy endpoint uses an SSL connection.
159
+
160
+
In that scenario, you can set the `PROXY_URL` environment variable to target the test proxy at an HTTPS URL:
161
+
162
+
```text
163
+
PROXY_URL='https://localhost:5001'
164
+
```
165
+
166
+
The test proxy's certificate is [automatically configured][cert_setup] during proxy startup, though async tests may
0 commit comments