Add unit tests for Dart/Flutter integration improvements#7
Add unit tests for Dart/Flutter integration improvements#7chaudhary-keshav wants to merge 3 commits into
Conversation
chaudhary-keshav
commented
Mar 23, 2026
chaudhary-keshav
commented
- Implement tests for scanner field mapping including getters, setters, exports, library name, and package name.
- Add tests for file classifier to detect Dart generated files.
- Include tests for discovery extractor to verify Dart framework hints.
- Create tests for compressor output to ensure new fields are handled correctly.
- Add tests for BPL selector to count new Dart artifacts.
- Verify ProjectMatrix includes new Dart fields and their serialization.
- Implement full parser integration tests for mixed Dart files with getters, setters, and exports.
- Implement tests for scanner field mapping including getters, setters, exports, library name, and package name. - Add tests for file classifier to detect Dart generated files. - Include tests for discovery extractor to verify Dart framework hints. - Create tests for compressor output to ensure new fields are handled correctly. - Add tests for BPL selector to count new Dart artifacts. - Verify ProjectMatrix includes new Dart fields and their serialization. - Implement full parser integration tests for mixed Dart files with getters, setters, and exports.
There was a problem hiding this comment.
Pull request overview
Adds/extends Dart/Flutter integration support by introducing new Dart artifacts in the scan matrix (getters/setters/exports + library/package metadata), updating compression and discovery logic, and adding unit tests around these behaviors.
Changes:
- Add new Dart fields to
ProjectMatrixand populate them during Dart parsing. - Extend generated-file detection for common Dart codegen suffixes and add Dart pubspec framework hint extraction.
- Add unit tests validating Dart parser extraction, classifier behavior, discovery hints, compressor output, and matrix serialization for the new fields.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| tests/unit/test_dart_flutter_improvements.py | Adds tests for Dart getters/setters/exports, classifier suffixes, discovery hints, compressor output, BPL significance, and ProjectMatrix.to_dict() serialization. |
| docs/COPILOT_SUPPORTED_TECHNOLOGIES.md | Adds a large documentation page describing supported technologies/capabilities. |
| codetrellis/scanner.py | Adds new Dart fields to ProjectMatrix, serializes them in to_dict(), and maps parser results into the matrix during _parse_dart(). |
| codetrellis/file_classifier.py | Marks additional Dart codegen suffixes as generated. |
| codetrellis/extractors/discovery_extractor.py | Adds Dart/Flutter framework hints and parses pubspec.yaml for project name/description/framework hints. |
| codetrellis/compressor.py | Extends Dart compression output to include getters/setters/exports and library/package metadata. |
| codetrellis/bpl/selector.py | Includes new Dart artifact lists in the Dart significance count. |
| Covers: | ||
| - Scanner field mapping for getters, setters, exports, library_name, package_name | ||
| - File classifier Dart generated file detection | ||
| - Discovery extractor Dart framework hints from pubspec.yaml | ||
| - Compressor output for new fields |
There was a problem hiding this comment.
The module docstring says these tests cover “Scanner field mapping…”, but the tests mostly exercise EnhancedDartParser.parse() directly and don’t validate ProjectScanner._parse_dart/ProjectMatrix field mapping (which is where the new mapping logic lives). Consider either adjusting the description or adding a test that runs the scanner parse path and asserts the matrix fields are populated as expected (this would also catch mapping bugs like setter param_type).
| # GitHub Copilot (Claude Opus) — Supported Technologies & Capabilities | ||
|
|
||
| > **Last Updated:** February 12, 2026 | ||
| > **Purpose:** An honest, comprehensive catalog of every software technology, language, framework, tool, and paradigm that this AI assistant can meaningfully work with — including writing, reviewing, debugging, refactoring, and architecting code. | ||
|
|
There was a problem hiding this comment.
This PR is described as adding unit tests for Dart/Flutter integration improvements, but it also adds a very large standalone capabilities catalog document. If this document isn’t required for the Dart/Flutter test changes, it should likely be split into a separate PR to keep scope focused (or the PR description updated to include it).
| "file": str(file_path), | ||
| "line": setter.line_number, | ||
| "param_type": setter.return_type or "", | ||
| "is_static": setter.is_static, |
There was a problem hiding this comment.
Setter mapping uses setter.return_type for param_type, but DartMethodInfo setters don’t populate return_type (they store the setter parameter in parameters). As a result, param_type will always be empty in the matrix. Populate param_type from the setter’s parameter list (e.g., first parameter’s type) instead of return_type.
| for setter in result.setters: | ||
| matrix.dart_setters.append({ | ||
| "name": setter.name, | ||
| "file": str(file_path), | ||
| "line": setter.line_number, | ||
| "param_type": setter.return_type or "", | ||
| "is_static": setter.is_static, | ||
| "class_name": setter.class_name or "", |
There was a problem hiding this comment.
In Dart setter mapping, param_type is currently sourced from setter.return_type, but DartMethodInfo setters don’t populate return_type; the parameter type is in setter.parameters (typically the first parameter’s .type). This will cause dart_setters[*].param_type to be blank/incorrect in the ProjectMatrix and downstream compressor/BPL outputs. Consider deriving param_type from setter.parameters[0].type (with a safe fallback when the parameter list is empty).
