docs: replace url edge cases in testing coverage docs

Author: 56kyle

docs/topics/06_testing-coverage.md

@@ -28,15 +28,15 @@ We evaluated the primary testing framework and coverage tools:
 
 ### Option 1: {mod}`unittest` (+ [coverage.py](coveragepy-documentation))
 
-- **Description:** [unittest](python:unittest) is Python's built-in testing framework, inspired by JUnit. Tests are written in classes inheriting from `unittest.TestCase`. [:term:`coverage.py`](coveragepy-documentation) is the standard standalone tool for measuring code coverage.
+- **Description:** [unittest](unittest-documentation) is Python's built-in testing framework, inspired by JUnit. Tests are written in classes inheriting from `unittest.TestCase`. [:term:`coverage.py`](coveragepy-documentation) is the standard standalone tool for measuring code coverage.
 - **Evaluation:**
 
   - **Ease of Use:** Moderate. Requires significant boilerplate (class definitions, inheritance, specific method names, explicit `setUp`/`tearDown` methods). Writing simple tests is more verbose than alternatives.
   - **Feature-Rich:** Moderate. Provides core testing features but lacks the advanced features and extensive plugin ecosystem of [:term:`pytest`](pytest-documentation) (e.g., simple functional fixtures, powerful parametrization decorators built-in).
   - **Performance:** Moderate. Test execution can be slower than [:term:`pytest`](pytest-documentation) for large test suites due to its architecture (creating a class instance per test method). [:term:`coverage.py`](coveragepy-documentation) performance is generally good.
-  - **OS Interoperability:** Excellent. Both are foundational Python tools, highly robust across OSs. [unittest](python:unittest) is standard library, [:term:`coverage.py`](coveragepy-documentation) is pure Python.
-  - **Integration:** High (Individual). Both have CLIs easily called from Task Automation/CI. Integrating them _together_ requires explicitly wrapping `unittest` execution with `coverage run -m unittest` or using less standardized plugins compared to the [:term:`pytest`](pytest-pytest-cov-documentation) ecosystem. Generating standard reports like JUnit XML also often requires extra steps or third-party runners for [unittest](python:unittest).
-  - **Reporting:** Moderate (Test) / Excellent (Coverage). [unittest](python:unittest) provides basic terminal output. [:term:`coverage.py`](coveragepy-documentation) provides excellent, standard reports (text, HTML, XML).
+  - **OS Interoperability:** Excellent. Both are foundational Python tools, highly robust across OSs. [unittest](unittest-documentation) is standard library, [:term:`coverage.py`](coveragepy-documentation) is pure Python.
+  - **Integration:** High (Individual). Both have CLIs easily called from Task Automation/CI. Integrating them _together_ requires explicitly wrapping `unittest` execution with `coverage run -m unittest` or using less standardized plugins compared to the [:term:`pytest`](pytest-pytest-cov-documentation) ecosystem. Generating standard reports like JUnit XML also often requires extra steps or third-party runners for [unittest](unittest-documentation).
+  - **Reporting:** Moderate (Test) / Excellent (Coverage). [unittest](unittest-documentation) provides basic terminal output. [:term:`coverage.py`](coveragepy-documentation) provides excellent, standard reports (text, HTML, XML).
   - **Maturity & Stability:** Very High. Both are extremely mature, stable, battle-tested.
   - **Community & Documentation:** Very High. Widely adopted, vast documentation.
 
@@ -47,9 +47,9 @@ We evaluated the primary testing framework and coverage tools:
 - **Description:** A popular, feature-rich testing framework that allows writing tests using standard Python functions or methods, greatly reducing boilerplate.
 - **Evaluation:**
 
-  - **Ease of Use:** Very High. Simple function-based tests (`def test_something(): assert ...`). Intuitive organization. Powerful built-in parametrization (`@pytest.mark.parametrize`). Much less boilerplate than [unittest](python:unittest).
+  - **Ease of Use:** Very High. Simple function-based tests (`def test_something(): assert ...`). Intuitive organization. Powerful built-in parametrization (`@pytest.mark.parametrize`). Much less boilerplate than [unittest](unittest-documentation).
   - **Feature-Rich:** Excellent. Sophisticated fixture system, powerful parametrization, extensive plugin ecosystem for various testing needs (mocking, async, specific frameworks), robust hook system.
-  - **Performance:** High. Generally faster execution on large test suites than [unittest](python:unittest). Efficient test discovery.
+  - **Performance:** High. Generally faster execution on large test suites than [unittest](unittest-documentation). Efficient test discovery.
   - **OS Interoperability:** Excellent. Pure Python package, works reliably across OSs.
   - **Integration:** Excellent. Widely supported, integrates seamlessly into editors/IDEs, [:term:`pre-commit`](pre-commit-documentation), Task Automation, CI/CD. Designed for external execution via CLI.
   - **Reporting:** Excellent. Provides clear terminal output. Standard support for generating JUnit XML reports (`--junitxml=...`), which is essential for CI platform integration.
@@ -93,7 +93,7 @@ We evaluated the primary testing framework and coverage tools:
 
 - **Description:** A generic virtual environment and test automation tool. Primarily used for running tests against multiple Python interpreters and dependency matrixes. Often configured via `tox.ini`. (Note: Already evaluated conceptually in Task Automation as a potential tool invoked by Nox for specific matrix needs).
 - **Evaluation:**
-  - **Testing Framework:** Moderate. It's not a testing _framework_ like [:term:`pytest`](pytest-pytest-cov-documentation) or [unittest](python:unittest), but an _orchestrator_ that runs other tools (like `pytest`) within isolated environments. Requires learning Tox config (`tox.ini`).
+  - **Testing Framework:** Moderate. It's not a testing _framework_ like [:term:`pytest`](pytest-pytest-cov-documentation) or [unittest](unittest-documentation), but an _orchestrator_ that runs other tools (like `pytest`) within isolated environments. Requires learning Tox config (`tox.ini`).
   - **Matrix Testing:** Excellent. Historically one of the best tools for defining and running tests across complex Python version and dependency variations.
   - **Integration with Test Tools:** Excellent. Designed to run commands like `pytest` or `python -m unittest` within its managed environments.
   - **OS Interoperability:** High. Designed for cross-platform matrix testing. Can have nuances depending on underlying shell commands in `tox.ini`.
@@ -112,13 +112,13 @@ We evaluated the primary testing framework and coverage tools:
 
 The combination of **[:term:`pytest`](pytest-documentation)**, **[:term:`coverage.py`](coveragepy-coverage-documentation)**, and **[:term:`pytest-cov`](pytest-pytest-cov-documentation)** is the best fit for providing robust testing and coverage capabilities in this template, complemented by **[:term:`Nox`](nox-documentation)** for matrix execution:
 
-1.  **Developer Experience:** [:term:`pytest`](pytest-pytest-cov-documentation) offers significantly **easier test writing and organization** compared to [unittest](python:unittest), with powerful features like fixtures and parametrization that improve test maintainability and expressiveness (addressing **Ease of Use** and **Feature-Rich**). This aligns with the **"Obvious way to do it"** for writing tests.
+1.  **Developer Experience:** [:term:`pytest`](pytest-pytest-cov-documentation) offers significantly **easier test writing and organization** compared to [unittest](unittest-documentation), with powerful features like fixtures and parametrization that improve test maintainability and expressiveness (addressing **Ease of Use** and **Feature-Rich**). This aligns with the **"Obvious way to do it"** for writing tests.
 2.  **Standards and Integration:** [:term:`pytest`](pytest-pytest-cov-documentation) is the de facto standard modern Python testing framework, and [:term:`coverage.py`](coveragepy-coverage-documentation) is the universal coverage engine. **[:term:`pytest-cov`](pytest-pytest-cov-documentation)** provides **seamless, standard integration** between them via a simple command-line flag (`--cov`), making combined testing and coverage easy to run and automate (addressing **Integration**).
 3.  **Reporting:** This combination provides **excellent standard reporting**, including JUnit XML from [:term:`pytest`](pytest-pytest-cov-documentation) and Cobertura XML/HTML from [:term:`coverage.py`](coveragepy-coverage-documentation), which are essential for integration into CI/CD platforms (Area 13, 14) (addressing **Reporting**).
 4.  **Performance & OS Interoperability:** All chosen tools are **performant** for their tasks and **highly OS-interoperable**, working reliably across development and CI environments (addressing **Performance** and **OS Interoperability**).
 5.  **Matrix Testing:** While [:term:`pytest`](pytest-pytest-cov-documentation) itself isn't a matrix orchestrator, **[:term:`Nox`](nox-documentation)** (Area 12) is explicitly designed to run sessions (like our test session) across different Python versions and environments using `uv`, effectively providing the necessary matrix testing capability within the template's primary automation layer. For complex scenarios or community conventions, [:term:`Nox`](nox-documentation) can easily **invoke [:term:`Tox`](tox-documentation)**.
 
-[unittest](python:unittest) was discounted due to its comparative verbosity, lack of features, and less streamlined integration for testing+coverage. [:term:`Tox`](tox-documentation) is better suited as a matrix _runner_ called by [:term:`Nox`](nox-documentation) than the primary testing _framework_ itself.
+[unittest](unittest-documentation) was discounted due to its comparative verbosity, lack of features, and less streamlined integration for testing+coverage. [:term:`Tox`](tox-documentation) is better suited as a matrix _runner_ called by [:term:`Nox`](nox-documentation) than the primary testing _framework_ itself.
 
 By choosing this combination, the template leverages the strengths of each tool – [:term:`pytest`](pytest-pytest-cov-documentation) for writing tests, [:term:`coverage.py`](coveragepy-coverage-documentation) for coverage, [:term:`pytest-cov`](pytest-pytest-cov-documentation) for integration, and [:term:`Nox`](nox-documentation) for orchestration – to provide a robust, modern, and well-integrated testing and coverage solution.