In this article
Test basics
What is pytest, and why use it instead of unittest?
Pytest is a Python test framework that runs tests written as plain functions with plain assert statements, so a test needs no base class and no special assertion methods. It also runs tests written for the standard-library unittest module. Interviewers expect the practical reasons: less boilerplate, fixtures for setup, and readable failure output that shows the values on both sides of a failed comparison.
Why it is asked: it checks that you have used the tool rather than only read its name. Read more: the coding interview guide covers where testing questions sit in a round.
How does pytest find tests?
By naming convention. Pytest collects files named like test_*.py or *_test.py, then functions whose names start with test, and methods starting with test inside classes whose names start with Test (pytest documentation, good practices, accessed October 2026). Running pytest with no arguments searches the current directory and below. If a test is silently not running, the first thing to check is its name.
Why it is asked: a missing test that nobody notices is a classic real-world bug. Read more: the JUnit questions show how another ecosystem handles discovery.
Why does pytest use plain assert instead of assertEqual?
Pytest rewrites assert statements when it imports test modules, so a failing assert a == b reports the values of both sides without a special method (pytest documentation, assertions, accessed October 2026). That is why a test can say what it means in ordinary Python. The practical point for an interview: the rewriting applies to test modules, so helper assertions in other modules need extra care to give the same detail.
Why it is asked: it separates users who know the mechanism from users who only like the syntax. Read more: the quality assurance (QA) interview questions cover test design more widely.
Fixtures
What is a fixture in pytest?
A fixture is a function, marked with the @pytest.fixture decorator, that provides a test with data or prepared state; a test asks for it by naming it as a parameter. Pytest runs the fixture before the test and passes in its result. Fixtures replace the setup and teardown methods of unittest, and one fixture can request another, which builds setup in layers.
Why it is asked: fixtures are the feature most pytest questions grow from. Read more: How to use fixtures, pytest documentation, accessed October 2026.
What are the fixture scopes, and what is the default?
The default scope is function, so the fixture is destroyed at the end of each test. The class scope ends with the last test in the class, module with the last test in the module, and session at the end of the test session (pytest documentation, fixtures, accessed October 2026). A package scope also exists. Wider scope trades isolation for speed.
Why it is asked: choosing a scope shows whether you weigh test speed against test independence. Read more: pytest fixtures reference.
How many times does setup run for each scope?
In an illustrative suite of 12 tests in 3 modules, each module holding 2 classes of 2 tests, a function-scoped fixture runs setup 12 times, a class-scoped one 6 times, a module-scoped one 3 times and a session-scoped one once.1 The count depends on how tests are grouped, but it is plain arithmetic: one setup per test, class, module or session.
Text description of the diagram
- Function scope runs setup 12 times in the illustrative suite.
- Session scope runs setup once.
Why it is asked: it turns the scope definitions into a cost you can estimate. Read more: the coding interview guide for how to explain a cost estimate aloud.
How do you do teardown in a fixture?
Use a yield fixture, which is a fixture that uses yield instead of return. The code before the yield is setup, the yielded object goes to the test, and the code after the yield runs as teardown when the fixture's scope ends. The documentation presents this as the recommended approach over registering finalizer callbacks (pytest documentation, fixtures, accessed October 2026).
Why it is asked: leaked files, connections and processes are common causes of flaky suites. Read more: How to use fixtures.
What happens if a test requests the same fixture twice?
The fixture runs once for that test. The documentation states that a fixture can be requested more than once during the same test and pytest does not execute it again for that test (pytest documentation, fixtures, accessed October 2026). Two fixtures that both depend on a third therefore share one instance of it within the test.
Why it is asked: it tests whether you know fixture results are cached per request chain, not recomputed at each mention. Read more: How to use fixtures.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Sharing and automatic use
What is conftest.py?
The file conftest.py is a special file in which fixtures are placed so that tests from several test modules in its directory can use them without importing them. The documentation shows a fixture moved there with module scope for exactly this purpose (pytest documentation, fixtures, accessed October 2026). Its fixtures apply to its own directory and every directory below it, and the file can also hold hooks and local plugins. A test never imports from it; pytest finds the fixtures by name.
Why it is asked: it shows whether you can organize a suite beyond one file. Read more: How to use fixtures.
What is an autouse fixture?
An autouse fixture is a fixture that every test in its scope requests automatically, without naming it as a parameter. You make one by passing autouse=True to the fixture decorator (pytest documentation, fixtures, accessed October 2026). It suits cross-cutting setup such as resetting global state. The cost is hidden behavior, because a reader of a test cannot see it.
Why it is asked: it tests judgment about implicit versus explicit setup. Read more: How to use fixtures.
Can a fixture's scope be decided at run time?
Yes, through dynamic scope: pass a callable instead of a string to scope. Pytest calls it once, when the fixture is defined, with the keyword arguments fixture_name and config, and uses the scope name it returns. The documentation marks this as added in version 5.2 (pytest documentation, fixtures, accessed October 2026). A typical use is a command-line option that widens the scope when the environment is expensive to build.
Why it is asked: it is a depth check for candidates who claim long experience. Read more: How to use fixtures.
How do parametrized fixtures interact with scope?
Pytest caches only one instance of a fixture at a time, so with a parametrized fixture it may invoke the fixture more than once within a scope (pytest documentation, fixtures, accessed October 2026). A module-scoped fixture with several parameters is therefore set up again each time the parameter changes, not once per module. Plan expensive setup with that in mind.
Why it is asked: it catches the assumption that wider scope always means a single setup. Read more: How to use fixtures.
Parametrization and markers
What does pytest.mark.parametrize do?
It runs one test function several times with different argument sets, and each set is reported as its own test (pytest documentation, parametrize, accessed October 2026). You name the arguments and give a list of values, so one function replaces a copy-pasted block of near-identical tests. Giving each case a readable id makes failures easy to find. Keep the cases independent so one failure does not hide the others.
Why it is asked: table-driven tests are standard practice and a quick check of test design. Read more: the Java automation testing questions show the same idea in another toolchain.
What are markers, and how do skip and xfail differ?
A marker is a label attached to a test with @pytest.mark.<name>. A skip marker says the test is not run, usually because it does not apply to the current platform or version. An xfail marker says the test is run but is expected to fail, which records a known bug without turning the suite red. Register custom markers and run with --strict-markers, so a typo becomes an error.
Why it is asked: it tests how you handle known failures without hiding them. Read more: the full stack developer questions place testing inside wider role expectations.
Built-in fixtures, test doubles, selection and configuration
How do you replace a dependency in a pytest test?
Use the built-in monkeypatch fixture. It temporarily changes an attribute, dictionary item or environment variable for one test, and pytest undoes the change when the test ends. monkeypatch.setattr swaps a function or class for a test double, setenv sets an environment variable and setitem changes a dictionary. Because the change is reverted automatically, a replaced dependency cannot leak into the next test (pytest documentation, monkeypatch, accessed October 2026).
Why it is asked: it tests whether you can isolate code from networks, clocks and files. Read more: How to monkeypatch.
Which built-in fixtures should you know?
Four come up most. tmp_path gives each test a fresh temporary directory. capsys captures what the code writes to standard output and standard error so the test can assert on it. monkeypatch replaces dependencies, as above. request gives a fixture information about the test that asked for it, and in a parametrized fixture request.param holds the current parameter (pytest documentation, fixtures reference, accessed October 2026).
Why it is asked: knowing the built-ins shows you do not rebuild what pytest already provides. Read more: pytest fixtures reference.
How do you run only some tests?
Name the file or a single test, as in pytest tests/test_a.py::test_name. Then narrow by name with -k "expression" or by marker with -m name. The option -x stops at the first failure, and --lf reruns only the tests that failed in the previous run (pytest documentation, invoking pytest, accessed October 2026). Markers make the selection stable, because names change.
Why it is asked: fast feedback while debugging is a daily skill. Read more: How to invoke pytest.
Where does pytest configuration live?
In a configuration file at the project root: pytest.ini, a [tool.pytest.ini_options] table in pyproject.toml, tox.ini or setup.cfg. Typical settings are default command-line options (addopts), registered markers and the directories to search for tests. The file also fixes the root directory that pytest reports paths against (pytest documentation, configuration, accessed October 2026).
Why it is asked: it shows whether you have set up a suite, not only written tests. Read more: Configuration.
What are pytest plugins, and which are common?
A plugin is a package or module that adds fixtures, hooks or command-line options to pytest; installed plugins load automatically, and a conftest.py can act as a local plugin. Two common ones are pytest-xdist, which runs tests in parallel across processes, and pytest-cov, which reports test coverage. Parallel runs need tests that do not share state.
Why it is asked: it checks whether you know how pytest is extended in real projects. Read more: the QA interview questions.
Exceptions and numbers
How do you test that code raises an exception?
Use pytest.raises as a context manager around the call that should fail, naming the expected exception type. The test passes if that exception is raised inside the block and fails if nothing is raised or a different exception type appears. You can also keep the exception object and check its message. A bare try and except in a test can pass silently when nothing is raised, which is why raises is preferred.
Why it is asked: error paths are tested less often than happy paths, and interviewers know it. Read more: How to write and report assertions.
Why does 0.1 + 0.2 == 0.3 fail, and what do you use instead?
Binary floating point cannot store 0.1 exactly, so in Python the sum prints as 0.30000000000000004 and the comparison is false.1 The documentation shows 0.1 + 0.2 == 0.3 evaluating to false, and recommends pytest.approx, which asserts that two numbers are equal within some tolerance (pytest documentation, application programming interface (API) reference, accessed October 2026). Write assert 0.1 + 0.2 == pytest.approx(0.3).
Why it is asked: it checks that you know floating point before you write numeric tests. Read more: pytest API reference, approx.
Is a fixed absolute tolerance like 1e-6 good enough?
No single absolute tolerance suits every case. The documentation says a check such as abs((0.1 + 0.2) - 0.3) < 1e-6 is true here but usually discouraged, because 1e-6 is fine for numbers around 1, too small for very big numbers and too big for very small ones (pytest documentation, API reference, accessed October 2026). By default approx uses a relative tolerance of 1e-6 and an absolute tolerance of 1e-12 (pytest documentation, API reference, accessed October 2026). Use approx and set the tolerance to the scale of your data.
Why it is asked: it separates a memorised trick from understanding relative and absolute error. Read more: pytest API reference, approx.
Does approx work on things other than numbers?
Since version 6.1.0, approx falls back to strict equality for non-numeric types instead of raising a TypeError (pytest documentation, API reference, accessed October 2026). It also accepts ordered sequences of numbers, so you can compare two lists of floats in one assertion. Check the installed version if an older project behaves differently.
Why it is asked: it tests whether you read release notes and know version differences. Read more: pytest API reference, approx.
Follow-up questions
What are the common pytest interview questions?
The twenty-three above cover what a pytest round usually turns on: how tests are found, what a fixture is, how scope and teardown work, how to parametrize, how to replace a dependency, how to select tests, and how to compare floats and exceptions. For the wider round, read the coding interview guide.
What pytest questions are asked for experienced testers?
Expect depth on the same topics: scope trade-offs, parametrized fixtures, dynamic scope, shared fixtures in conftest.py, and suite design that keeps tests independent. Be ready to explain a trade-off, such as a module-scoped fixture's speed against its shared state. Compare how JUnit and the QA interview questions frame similar ground.
How do I prepare for a pytest coding round?
Write a small function, then write its tests with a fixture, a parametrized case and a raises check, and say your reasoning aloud. Practice the routine in the coding interview guide, and try the same exercise in another language through the JavaScript or Java question lists.
- Pytest tests are plain functions with plain
assert; names decide what is collected. - A fixture's default scope is function; wider scopes run setup less often but share state.
- Yield fixtures put teardown after the
yield; autouse fixtures apply without being named. - Parametrized fixtures can run more than once inside a wider scope.
- Compare floats with
pytest.approx, not==, and not with one fixed tolerance.
Sources
- How to use fixtures (pytest documentation, stable) — pytest-dev, 26 Oct 2026
- API Reference, pytest.approx (pytest documentation, stable) — pytest-dev, 26 Oct 2026
- How to parametrize fixtures and test functions (pytest documentation, stable) — pytest-dev, 26 Oct 2026
- How to monkeypatch and mock modules and environments (pytest documentation, stable) — pytest-dev, 26 Oct 2026
- How to invoke pytest (pytest documentation, stable) — pytest-dev, 26 Oct 2026
- Configuration (pytest documentation, stable) — pytest-dev, 26 Oct 2026
- Fixtures reference, built-in fixtures (pytest documentation, stable) — pytest-dev, 26 Oct 2026
- How to write and report assertions in tests (pytest documentation, stable) — pytest-dev, 26 Oct 2026
- Good Integration Practices (pytest documentation, stable) — pytest-dev, 26 Oct 2026
