Feat/50 add has tests field

JOURNAL.md

@@ -0,0 +1,167 @@
+# PathReview Contribution Journal
+
+## Week 7 — Issue selection
+
+**Issue link:** https://github.com/ascherj/pathreview/issues/50
+
+**Issue title:** Add a has_tests boolean to the repo analysis output
+
+**Tier:** [x] Tier 1  [ ] Tier 2  [ ] Tier 3
+
+**Problem summary:**
+
+The repository analysis output currently does not indicate whether a project includes automated tests. This makes it harder to use test coverage as a signal of repository quality and portfolio readiness. The change will inspect repository contents for common testing indicators, including `tests/` or `test/` directories, a `pytest.ini` file, and Python files matching `test_*.py`. A successful implementation will expose the result as a `has_tests` boolean in the repository analysis output.
+
+**Selection notes and scope reasoning:**
+
+- The issue has clear acceptance criteria.
+- The change is limited primarily to `agent/tools/github_tool.py` and `agent/tools/repo_analyzer.py`.
+- The required detection rules are concrete and testable.
+- The estimated effort of 2–4 hours fits the Module 3 timeline.
+- I can verify the implementation using repositories with and without test files.
+
+**Branch name:** feat/50-add-has-tests-field
+
+**Setup confirmation:** [x] App runs locally at localhost:5173
+
+**Cohort ledger:** [x] Issue added to cohort ledger
+
+## Implementation progress so far:
+
+Progress so far:
+
+I implemented the has_tests boolean in ingestion/parsers/repo_analyzer.py. The analyzer now detects common testing indicators, including tests/ and test/ directories, pytest.ini, Python files matching test_*.py, __tests__, and spec/.
+
+During testing, I found that the initial implementation incorrectly detected non-Python files such as docs/test_notes.md. I updated the logic so that files beginning with test_ must also end with .py.
+
+Tests added:
+
+Detects test_*.py
+Detects a tests/ directory
+Detects a test/ directory
+Detects pytest.ini
+Returns false when no tests exist
+Prevents false positives for files such as test_notes.md
+
+Verification:
+
+Focused repository analyzer tests: 6 passed
+Full test suite: 381 passed, 53 failed, 2 warnings
+The full-suite failures are in unrelated modules and do not involve RepoAnalyzer
+
+
+Pull request: Add has_tests boolean to repository analysis
+https://github.com/ascherj/pathreview/pull/925
+
+Implementation summary:
+
+I completed the has_tests feature for repository analysis. The parser now detects common automated-testing indicators and includes the result in both the generated repository summary and parser metadata.
+
+Edge cases handled:
+
+Python files matching test_*.py
+tests/ directories
+test/ directories
+pytest.ini
+__tests__ directories
+spec/ directories
+Repositories without tests
+Non-Python files such as test_notes.md
+
+Verification:
+
+Focused repository analyzer tests: 6 passed
+Full test suite: 381 passed, 53 failed, 2 warnings
+The full-suite failures are unrelated to this feature
+GitHub CI: [replace with passed, failed, or pending]
+
+What I learned:
+
+The initial implementation handled the main case but produced a false positive for a Markdown file beginning with test_. Adding a targeted edge-case test exposed the issue and helped make the detection logic more precise. I also verified the feature in the project’s required Python 3.11 environment and ran the complete test suite before submitting the pull request.
+
+
+
+
+## Week 9 — Pull request submission
+### Pull request
+
+**PR link:** https://github.com/ascherj/pathreview/pull/925
+
+**PR title:** Add has_tests boolean to repository analysis
+
+### Implementation summary
+
+I completed the `has_tests` feature for repository analysis. The analyzer now checks repository contents for common automated testing indicators and includes the result as a boolean in the repository analysis output.
+
+The implementation detects:
+
+- `tests/` directories
+- `test/` directories
+- `pytest.ini`
+- Python files matching `test_*.py`
+- `__tests__/` directories
+- `spec/` directories
+
+I also added an edge-case test to prevent non-Python files such as `test_notes.md` from being incorrectly classified as tests.
+
+### Testing and verification
+
+- Focused repository analyzer tests: 6 passed
+- Full test suite: 381 passed, 53 failed, 2 warnings
+- The full-suite failures were in unrelated modules and did not involve `RepoAnalyzer`
+
+### What I learned
+
+One important issue I found during testing was that my initial implementation treated any file beginning with `test_` as a test file. This caused false positives for files such as `test_notes.md`. Adding a targeted edge-case test helped me catch the problem and refine the detection logic so that `test_` files must also end in `.py`.
+
+I also learned the importance of testing both the specific functionality I changed and the larger project test suite before submitting a pull request.
+
+
+
+
+
+
+## Week 10 — Iteration & reflection
+### Reviewer feedback
+
+**Feedback received:** [ ] Yes  [x] No — still awaiting review
+
+**Summary of feedback:**
+
+No reviewer or maintainer feedback was received for the pull request during Summer 2026.
+
+**How you responded:**
+
+No response or code changes were required because reviewer feedback was not provided.
+
+---
+
+### Reflection
+
+**What was harder than you expected?**
+
+Understanding the existing repository structure and deciding where the `has_tests` logic belonged was harder than I expected. I also had to think beyond the basic acceptance criteria and handle edge cases correctly. For example, my initial implementation treated files such as `test_notes.md` as test files because they started with `test_`. Writing targeted tests helped me identify that false positive and refine the detection logic.
+
+---
+
+### Reflection
+
+**What was harder than you expected?**
+
+Understanding the existing repository structure and deciding where the `has_tests` logic belonged was harder than I expected. I also had to think beyond the basic acceptance criteria and handle edge cases correctly. For example, my initial implementation treated files such as `test_notes.md` as test files because they started with `test_`. Writing targeted tests helped me identify that false positive and refine the detection logic.
+
+**What did you learn about working in a large codebase?**
+
+I learned that contributing to an existing codebase requires more than just implementing the requested feature. I had to understand the repository structure, follow existing patterns, avoid changing unrelated behavior, and verify that my changes did not break other parts of the project. I also learned that focused tests are important, but running the broader test suite gives additional confidence about how a small change interacts with the rest of the codebase.
+
+**How did AI tools help — and where did they fall short?**
+
+AI tools were useful for understanding unfamiliar parts of the codebase, suggesting implementation approaches, debugging test failures, and helping me think through edge cases. However, I still had to verify the suggestions against the actual repository behavior and test results. AI did not automatically know which failures were caused by my change versus unrelated existing issues, so I had to inspect the test output and validate the implementation myself.
+
+**What would you do differently if you started over?**
+
+I would spend more time at the beginning tracing the relevant code paths and existing tests before writing the implementation. That would have helped me identify the expected patterns and edge cases earlier. I would also add negative test cases, such as non-Python files beginning with test_, from the start instead of discovering them after the initial implementation.
+
+**What are you most proud of from this module?**
+
+I am most proud of taking a real issue from selection through implementation, testing, and pull request submission in an unfamiliar codebase. I was able to catch and fix an edge case through testing rather than stopping once the basic feature worked, which made the final implementation more reliable.

PLAN.md

@@ -0,0 +1,98 @@
+# Solution Plan
+
+**Issue:** Add detection logic that checks whether a repository has a `tests/` or `test/` directory, a `pytest.ini`, or test files matching `test_*.py`, and expose this as a boolean field in the analysis output.
+
+## Understand
+
+The goal of this issue is to identify whether a GitHub repository contains automated tests and expose that information as a boolean field (`has_tests`) in the repository analysis output.
+
+While tracing the codebase, I found that `RepoAnalyzer` already contains logic to detect test-related files and directories through `_detect_tests()`. However, the detection is broader than the issue specification. For example, it currently checks whether `"test_"` appears anywhere in the file structure, which incorrectly treats files such as `docs/test_notes.md` as Python test files.
+
+I reproduced this behavior by adding a unit test where the repository contains `docs/test_notes.md`. The current implementation reports `has_tests=True`, even though the issue specifically requires matching Python test files (`test_*.py`).
+
+## Map
+
+During investigation, I traced the repository metadata flow through these files:
+
+- `agent/tools/github_tool.py`
+  - Fetches GitHub repository metadata from the GitHub API.
+  - Currently returns repository metadata such as language, stars, README status, and topics.
+
+- `ingestion/parsers/repo_analyzer.py`
+  - Analyzes repository metadata.
+  - Contains `_detect_tests()`, which determines the `has_tests` value from the repository's `file_structure`.
+
+- `ingestion/pipeline.py`
+  - Passes the repository metadata into `RepoAnalyzer.parse()` during repository ingestion.
+
+- `tests/unit/test_repo_analyzer.py`
+  - Added a reproduction test showing that the current detection logic incorrectly classifies `docs/test_notes.md` as a Python test file because it checks for `"test_"` instead of `test_*.py`.
+
+## Plan
+
+1. Review the current `_detect_tests()` implementation in `RepoAnalyzer` and compare it against the issue requirements.
+2. Update the detection logic so it only recognizes the required indicators:
+   - `tests/`
+   - `test/`
+   - `pytest.ini`
+   - Python test files matching `test_*.py`
+3. Add unit tests covering both valid and invalid cases, including files such as `docs/test_notes.md` that should not be detected as test files.
+4. Run the unit tests to verify the updated behavior and ensure existing functionality is not broken.
+
+## Inputs & outputs
+
+**Input**
+
+The repository metadata passed to `RepoAnalyzer.parse()`, including the repository file structure.
+
+Example:
+
+```python
+{
+    "name": "sample-project",
+    "language": "Python",
+    "file_structure": [
+        "app.py",
+        "tests/test_app.py",
+        "pytest.ini",
+    ],
+}
+```
+
+**Output**
+
+The analyzer should correctly set the `has_tests` boolean in the metadata.
+
+Examples:
+
+```python
+result.metadata["has_tests"] == True
+```
+
+or
+
+```python
+result.metadata["has_tests"] == False
+```
+
+---
+
+## Risks & unknowns
+
+- I need to verify whether the detection should only support Python test files (`test_*.py`) or whether other conventions (such as `spec/` or `__tests__/`) should remain supported.
+- The current implementation checks for `"test_"` anywhere in the file structure, so changing it could affect existing behavior.
+- I also need to confirm that any changes remain compatible with the rest of the ingestion pipeline.
+
+---
+
+## Edge cases
+
+The implementation should handle:
+
+- Repositories containing a `tests/` directory.
+- Repositories containing a `test/` directory.
+- A root-level `pytest.ini`.
+- Python files matching `test_*.py`.
+- Repositories without any tests.
+- Files such as `docs/test_notes.md` that should **not** be detected as Python test files.
+- Empty or missing `file_structure` data.