Topic: Why the repo maintains both test*.py (pytest) and testertest_*.py (standalone) files across all implementations

Date: 2026-05-29

Time: 06:25

Why Both test*.py and testertest_*.py Exist

The repo maintains two parallel test suites per implementation, each serving a different execution model.

test_*.py — Pytest-integrated test suites

These are conventional pytest files: they import pytest (24 matches across the repo), use bare assert statements, and rely on pytest's test runner for discovery, execution, and reporting. They contain richer coverage — bloom-filter/testbloomfilter.py is 207 lines with additional edge cases like random-string testing, while the corresponding tester file is 125 lines. They have no if _name_ blocks, meaning they're designed exclusively to run via pytest.

testertest*.py — Standalone verification scripts

Every one of these files includes an if _name == "main": block (13 matches found). They're designed to run as plain Python scripts: python testertestbtree.py. The critical marker is the print("testbasicputget PASSED") pattern visible at b-tree-storage-engine/testertestbtree.py:49 — this is output-based validation, where a runner checks stdout for "PASSED" strings rather than relying on pytest's exit code and structured reporting.

The naming is intentional: testertest*.py does not match pytest's default discovery pattern (test*.py or *test.py), so these files are invisible to pytest unless explicitly targeted. This prevents double-counting when running pytest across the repo.

Why the duplication?

The two suites target different consumers:

| Dimension | test*.py | testertest_*.py |

|-----------|-------------|---------------------|

| Runner | pytest | python directly |

| Dependencies | Requires pytest | Some import pytest for fixtures, many don't |

| Output | Pytest report (exit code) | Stdout PASSED/FAILED lines |

| Discovery | Auto-discovered by pytest | Must be invoked explicitly |

| Coverage | Broader, more edge cases | Focused on core invariants |

The testertest*.py files act as a zero-dependency validation harness — they verify that each implementation meets its behavioral contract without requiring any test framework infrastructure. This is the kind of design you see in educational repos or automated grading systems, where the verifier must run in minimal environments. The pytest files then layer on top with more thorough coverage for development use.

Note that the boundary isn't perfectly clean: several tester files (bloom-filter/testertestbloomfilter.py:4, fencing-tokens/testertestfencingtokens.py:2, consistent-hashing/testertestconsistent_hashing.py:3) still import pytest for markers or fixtures, suggesting they evolved from the pytest files or were written pytest-compatible as a convenience even though their primary use case is standalone execution.

Beliefs

• tester-files-are-standalone-runnable — Every testertest*.py file contains an if _name == "main_": block, making it executable via python without pytest.
• tester-naming-avoids-pytest-discovery — The testertest*.py prefix does not match pytest's default collection patterns (test*.py / *test.py), so these files are excluded from pytest runs unless explicitly specified.
• tester-files-use-stdout-validation — Tester files print "test_name PASSED" to stdout, indicating an output-parsing runner rather than pytest's exit-code-based reporting.
• pytest-files-have-broader-coverage — The test*.py files are consistently longer than their testertest_*.py counterparts (e.g., 207 vs 125 lines for bloom-filter, 300 vs 200 for b-tree), containing additional edge case tests.
• tester-pytest-boundary-is-leaky — At least 6 testertest*.py files import pytest despite being designed for standalone execution, indicating the two suites share lineage rather than being fully independent.