|
6 | 6 |
|
7 | 7 | [](https://smarie.github.io/python-pytest-cases/) [](https://pypi.python.org/pypi/pytest-cases/) [](https://pepy.tech/project/pytest-cases) [](https://pepy.tech/project/pytest-cases) [](https://github.com/smarie/python-pytest-cases/stargazers) |
8 | 8 |
|
9 | | -!!! success "New `@pytest_fixture_plus` decorator is there, [check it out](#d-case-fixtures) !" |
| 9 | +!!! success "New `fixture_union` and `@pytest_parametrize_plus` are there, [check them out](#fixture_union) !" |
10 | 10 |
|
11 | 11 | Did you ever thought that most of your test functions were actually *the same test code*, but with *different data inputs* and expected results/exceptions ? |
12 | 12 |
|
@@ -275,6 +275,50 @@ This feature has been tested in very complex cases (several union fixtures, fixt |
275 | 275 | !!! note "fixture unions vs. cases" |
276 | 276 | If you're familiar with `pytest-cases` already, you might note `@cases_data` is not so different than a fixture union: we do a union of all case functions. If one day union fixtures are directly supported by `pytest`, we will probably refactor this lib to align all the concepts. |
277 | 277 |
|
| 278 | +### `@pytest_parametrize_plus` |
| 279 | + |
| 280 | +`@pytest_parametrize_plus` is a replacement for `@pytest.mark.parametrize` that allows you to include references to fixtures in the parameter values. Simply use `fixture_ref(<fixture>)` in the parameter values, where `<fixture>` can be the fixture name or fixture function. |
| 281 | + |
| 282 | +For example: |
| 283 | + |
| 284 | +```python |
| 285 | +import pytest |
| 286 | +from pytest_cases import pytest_parametrize_plus, pytest_fixture_plus, fixture_ref |
| 287 | + |
| 288 | +@pytest.fixture |
| 289 | +def world_str(): |
| 290 | + return 'world' |
| 291 | + |
| 292 | +@pytest_fixture_plus |
| 293 | +@pytest_parametrize_plus('who', [fixture_ref(world_str), |
| 294 | + 'you']) |
| 295 | +def greetings(who): |
| 296 | + return 'hello ' + who |
| 297 | + |
| 298 | +@pytest_parametrize_plus('main_msg', ['nothing', |
| 299 | + fixture_ref(world_str), |
| 300 | + fixture_ref(greetings)]) |
| 301 | +@pytest.mark.parametrize('ending', ['?', '!']) |
| 302 | +def test_prints(main_msg, ending): |
| 303 | + print(main_msg + ending) |
| 304 | +``` |
| 305 | + |
| 306 | +yields the following |
| 307 | + |
| 308 | +```bash |
| 309 | +> pytest -s -v |
| 310 | +nothing? |
| 311 | +nothing! |
| 312 | +world? |
| 313 | +world! |
| 314 | +hello world? |
| 315 | +hello world! |
| 316 | +hello you? |
| 317 | +hello you! |
| 318 | +``` |
| 319 | + |
| 320 | +Note: for this to be performed, the parameters are replaced with a union fixture. Therefore the relative priority order with standard 'mark' parameters will get impacted. You may solve this by replacing your mark parameters with `param_fixture`s (see [above](#param_fixtures).) |
| 321 | + |
278 | 322 | ## Main features / benefits |
279 | 323 |
|
280 | 324 | * **Separation of concerns**: test code on one hand, test cases data on the other hand. This is particularly relevant for data science projects where a lot of test datasets are used on the same block of test code. |
|
0 commit comments