To run multiple test cases for a function while isolating each case’s failure report via subTest, keeping the test suite concise yet diagnostic.

To convey the set of test inputs and expected outputs for the add function, enabling clear, per‑case failure reporting.

When writing a unit test for a function that takes two arguments and returns a value, and you need to verify several input‑output pairs without writing a separate test method for each.

Inside a unittest.TestCase subclass test method, typically after importing the function under test and before any teardown logic.

for <a>, <b>, <expected> in [<tuple>, ...]: with self.subTest(<a>=<a>, <b>=<b>): self.assertEqual(<func>(<a>, <b>), <expected>)

for <a>, <b>, <expected> in [<tuple-list>]: with self.subTest(<a>=<a>, <b>=<b>): self.assertEqual(<func>(<a>, <b>), <expected>)

a: int or any type, b: int or any type, expected: int or any type, add: callable taking two arguments and returning a value

• unittest.TestCase
• self.subTest
• self.assertEqual
• test fixtures
• parameterized testing
• test setup/teardown

• Using zip to separate args and expected lists
• using a list of dicts with keys 'a'
• 'b'
• 'expected'
• using pytest.param for labeled cases
• using a data‑provider decorator or external CSV/JSON source

1. Forgetting to unpack the tuple (e.g., for case in cases: self.assertEqual(add(case), expected)) → TypeError because add receives a single tuple instead of two separate arguments. 2. Omitting the keyword arguments in subTest (e.g., self.subTest(a, b)) → TypeError because subTest expects keyword arguments. 3. Reversing the order of arguments in assertEqual (self.assertEqual(expected, add(a, b))) → misleading failure messages and, for non‑commutative operations, hidden bugs. 4. Using the same label for every subTest (e.g., self.subTest()) → all iterations share the same subTest identity, causing failures to be merged and losing per‑case isolation. 5. Mismatching the number of elements in the tuple (e.g., providing only two values) → ValueError during unpacking.

pytest.mark.parametrize – more declarative, generates separate test IDs but groups failures under one test name; nose’s @parameterized – similar to pytest but requires an external plugin; unittest.TestCase.subTest with custom message – adds a descriptive label to each subTest; plain for loop without subTest – runs all iterations but stops reporting after the first failure unless manually caught.

Coming from pytest: may expect parametrize to create independent test reports, whereas subTest groups all iterations under one test method – use subTest for isolated reporting within a single test. Coming from nose: may forget to import unittest and use plain assert, leading to uncontrolled AssertionError that stops the test suite – use unittest.TestCase methods and subTest for proper test framework integration.

• unit test loop
• subTest usage
• assertEqual
• parameterized testing
• test fixture setup

Do not use this pattern when each test case needs completely independent setup/teardown that cannot be shared across iterations; the subTest context shares the same fixture state. Performance impact is negligible – the overhead is only the subTest context manager per iteration. A non‑obvious boundary condition is that subTest does not stop iteration on failure; all cases will run unless you explicitly break or raise an exception inside the block.

Ensures each test case is reported individually, making debugging faster while keeping the test suite concise and avoiding duplication of test methods.

Think of subTest as a safety net for each trapeze act – if one performer falls, the show continues and you know exactly who slipped.

The subTest context manager does not suppress exceptions; any uncaught exception inside the block will still propagate and be reported as a subTest failure.

Using pytest.mark.parametrize for more declarative, data‑driven test generation.