Add a New Statistics Tab

[7174Andy]

This pull request adds a new "Statistics" tab to the application's GUI, providing users with monthly financial insights such as net income and top spending category. To support these features, several new methods are introduced in the TransactionRepository for calculating monthly statistics and tracking months with available data. Comprehensive tests are also added to ensure correctness of these new repository methods.

Major additions and improvements:

1. Statistics Tab UI and Functionality

• Added a new StatisticsTab (statistics_tab.py) to the GUI, displaying monthly net income and top spending category with navigation controls for switching between months. The tab is integrated into the main window and supports lazy loading/refresh. [1] [2] [3] [4] [5]

2. Repository Methods for Monthly Statistics

• Implemented get_monthly_net_income, get_top_spending_category, get_latest_month_with_data, and get_all_months_with_data in TransactionRepository to provide the data needed for the statistics tab. These methods calculate net income, identify top spending categories, and determine available months for navigation. [1] [2]

These changes collectively enhance the application's ability to provide users with actionable financial insights and improve the robustness of the backend data calculations.

[Copilot]

Pull request overview

This PR introduces a new Statistics tab to the GUI, providing users with monthly financial insights including net income and top spending categories. The implementation follows a clean architecture with a new service layer for statistics calculations and comprehensive test coverage.

Key Changes:

• Added StatisticsService to combine repository operations into higher-level business logic
• Created StatisticsTab GUI component with month navigation and metric displays
• Extended TransactionRepository with methods for monthly statistics, cashflow trends, and data availability queries
• Refactored repository classes from a single module into separate files (transaction_repository.py and merchant_repository.py)

Reviewed changes

Copilot reviewed 15 out of 16 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
expense_tracker/services/statistics.py	New service layer combining repository calls for statistics calculations
expense_tracker/gui/tabs/statistics_tab.py	New Statistics tab with navigation controls and metric cards for net income and top spending
expense_tracker/core/transaction_repository.py	Added methods for monthly statistics, refactored spending queries to use date ranges, split from repositories.py
expense_tracker/core/merchant_repository.py	Extracted MerchantCategoryRepository to separate file from repositories.py
expense_tracker/gui/main_window.py	Integrated Statistics tab with lazy loading support
expense_tracker/gui/tabs/heatmap_tab.py	Updated to use StatisticsService instead of direct repository access
expense_tracker/gui/tabs/__init__.py	Exported StatisticsTab
expense_tracker/app.py	Created and injected StatisticsService dependency
tests/services/test_statistics.py	Comprehensive tests for StatisticsService covering all methods and edge cases
tests/core/test_repository.py	Added tests for new repository methods (net income, top category, month queries)
Multiple dialog/tab files	Updated imports to use new repository module structure

Comments suppressed due to low confidence (6)

expense_tracker/core/transaction_repository.py:177

• Unclear parameter description in docstring. The method accepts start_date and end_date parameters but the docstring only describes the return value without mentioning what date range the parameters represent. Consider adding an "Args:" section to clarify the purpose of these parameters, e.g., "Args: start_date: Start of date range (inclusive), end_date: End of date range (exclusive)".
  expense_tracker/core/transaction_repository.py:218
• Missing test coverage for get_monthly_cashflow_trend repository method. This new method is tested in the service layer (test_statistics.py:258-304) but lacks direct unit tests at the repository level. Consider adding tests in test_repository.py to verify edge cases like empty database, single month, and correct ordering/limiting behavior.
  expense_tracker/core/transaction_repository.py:315
• Return type annotation doesn't match actual return value. The method signature declares -> list[tuple[int, int]] but the implementation returns a set (line 315: return {(row["year"], row["month"]) for row in rows.fetchall()}). This inconsistency will cause type checking errors and unexpected behavior.

The tests expect a set (see test_get_all_months_with_data at line 1102), and the StatisticsService converts it to a list at line 83. Either change the return type annotation to -> set[tuple[int, int]] or change the return statement to return [(row["year"], row["month"]) for row in rows.fetchall()].
expense_tracker/core/transaction_repository.py:224

• The docstring says "for a specific month" but the parameters are start_date and end_date, which can represent any date range, not just a single month. The docstring should be updated to say "for a specific date range" to accurately describe the method's behavior.
  expense_tracker/core/transaction_repository.py:240
• The docstring says "for a specific month" but the parameters are start_date and end_date, which can represent any date range, not just a single month. The docstring should be updated to say "for a specific date range" to accurately describe the method's behavior.
  expense_tracker/core/transaction_repository.py:225
• This comment is obsolete and misleading. The method no longer creates a date range internally - it receives start_date and end_date as parameters. This comment should be removed.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.