Use this cheat sheet for PCAT-31-0x Certified Associate Tester with Python after you understand basic Python and need faster testing decisions. The exam lane is not only writing assertions. It is choosing the test type, isolating the defect, controlling fixtures, avoiding flaky dependencies, and preserving useful failure evidence.
PCAT answer sequence
flowchart TD
S["Scenario"] --> R["What risk or behavior must be tested?"]
R --> T["Choose unit, integration, regression, smoke, boundary, or negative test"]
T --> D["Control data, fixture, and dependency"]
D --> A["Assert one clear expected result"]
A --> E["Report evidence and prevent recurrence"]
If an answer makes the test pass but hides the failure mode, depends on test order, or calls unreliable external systems unnecessarily, it is usually weaker.
What to know cold
| Lane |
Decision rule |
Reject when |
| Test design |
Match the test to the risk: happy path, negative path, boundary, regression, or smoke. |
The answer tests only the common path when the defect is at an edge. |
| Assertions |
Assert one behavior clearly enough to diagnose failure. |
One test asserts many unrelated outcomes and gives vague failure output. |
| Fixtures |
Set up known state and clean it up without hidden order dependency. |
A test passes only because another test ran first. |
| Mocking |
Replace slow, flaky, costly, or external dependencies when the behavior under test is elsewhere. |
The mock hides the actual behavior being tested. |
| Data-driven tests |
Run the same rule over representative examples and edge cases. |
One hand-picked example stands in for the entire input class. |
| Regression tests |
Preserve a failing example after a defect is fixed. |
The bug is fixed without any test that would catch it next time. |
Scenario eliminations
| Stem clue |
Eliminate first |
Keep in play |
| production bug was fixed |
manual retest only |
regression test that reproduces the old failure |
| invalid input caused failure |
happy-path test only |
negative and boundary tests |
| external API is slow or flaky |
call real API in every unit test |
mock/fake the dependency and reserve integration test for the real path |
| tests pass locally but fail in suite |
hidden shared state |
isolated fixture and cleanup |
| one test failure gives unclear cause |
broad test with many assertions |
narrower test with named expected behavior |
| many values follow same rule |
copy-paste tests only |
parameterized or data-driven test |
| release confidence is needed fast |
full exhaustive suite only |
smoke test plus targeted regression suite |
Test-type chooser
| Requirement |
Strong first fit |
| check a single function with controlled inputs |
unit test |
| verify components work together |
integration test |
| ensure a fixed bug stays fixed |
regression test |
| quick release gate for basic health |
smoke test |
| invalid, missing, or malformed input |
negative test |
| min, max, empty, one, many, or threshold values |
boundary test |
| same behavior over many examples |
parameterized or data-driven test |
Python testing code cues
| Pattern |
Better instinct |
| test depends on previous test output |
create fixture state inside the test or fixture setup |
| test calls network by default |
mock/fake for unit scope; keep a separate integration check |
| assertion lacks message or clear expectation |
assert the exact outcome that proves the behavior |
| random input without seed or bounds |
make data reproducible and representative |
| temporary files left behind |
use temp directories and cleanup fixtures |
| skipped failure reproduction |
add regression test before or alongside the fix |
Final 15-minute review
| If the stem says… |
Start with |
| “bug returned” |
regression test and failing example |
| “edge case” |
boundary values and negative cases |
| “flaky test” |
dependency isolation, timing, order, randomness, and cleanup |
| “external service” |
mock for unit test, integration test for contract |
| “test data” |
representative values, expected result, and cleanup |
| “unclear failure” |
smaller assertion and better evidence |
Practice fit
PCAT practice should use short scenarios. For every answer, ask: what risk is being tested, what state is controlled, what dependency is isolated, and what evidence would help the next developer?