Skip to content

Commit f1f65bd

Browse files
offendingcommitclaude
offendingcommit
and
claude
committed
test: enhance testing infrastructure with comprehensive markers
- Add pytest.ini with detailed marker definitions for test categorization - Update Makefile with progressive test targets (test-unit, test-quick, test, test-e2e) - Create tests/README.md documenting test organization and marker usage - Implement testing pyramid strategy: 80% unit, 15% integration, 5% E2E 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
1 parent a628bfb commit f1f65bd

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

44 files changed

+6220
-234
lines changed

‎.gitignore‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -53,3 +53,7 @@ Thumbs.db
5353
# Poetry lock file (optional – some teams prefer to version-control this)
5454
poetry.lock
5555
.nicegui/
56+
.serena/cache/
57+
58+
# Game state persistence file
59+
game_state.json

‎.serena/memories/bingo_project_overview.md‎

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
# Bingo Project Overview
2+
3+
## Purpose
4+
A customizable bingo board generator built with NiceGUI and Python. Creates interactive bingo games for streams, meetings, or events with shareable view-only links.
5+
6+
## Tech Stack
7+
- **Language**: Python 3.12+
8+
- **UI Framework**: NiceGUI (reactive web UI)
9+
- **Package Manager**: Poetry
10+
- **Testing**: pytest with coverage
11+
- **Linting**: flake8, black, isort, mypy
12+
- **Containerization**: Docker
13+
- **Orchestration**: Kubernetes with Helm charts
14+
- **CI/CD**: GitHub Actions with semantic-release
15+
- **Web Server**: FastAPI (via NiceGUI)
16+
17+
## Project Structure
18+
- `app.py`: Main entry point (modular structure)
19+
- `main.py`: Legacy monolithic entry point
20+
- `src/`: Source code
21+
- `config/`: Configuration and constants
22+
- `core/`: Core game logic
23+
- `ui/`: UI components (routes, sync, controls, board)
24+
- `utils/`: Utilities (file operations, text processing)
25+
- `types/`: Type definitions
26+
- `tests/`: Unit and integration tests
27+
- `phrases.txt`: Customizable bingo phrases
28+
- `static/`: Static assets (fonts)
29+
- `helm/`: Kubernetes deployment configs
30+
31+
## Key Features
32+
- Custom phrases from file
33+
- Shareable view-only boards
34+
- Interactive click-to-mark tiles
35+
- Stream integration support
36+
- Responsive design
37+
- State persistence
38+
- Real-time synchronization between views
39+
40+
## Environment Variables
41+
- `PORT`: Port number (default: 8080)
42+
- `HOST`: Host address (default: 0.0.0.0)
43+
- `DEBUG`: Debug mode (default: False)

‎.serena/memories/code_style_conventions.md‎

Lines changed: 81 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,81 @@
1+
# Bingo Project - Code Style & Conventions
2+
3+
## Python Code Style
4+
5+
### General Guidelines
6+
- **Python Version**: 3.12+
7+
- **Line Length**: 88 characters (Black's default)
8+
- **Indentation**: 4 spaces (no tabs)
9+
- **String Formatting**: Use f-strings for interpolation
10+
11+
### Imports
12+
1. Standard library imports first
13+
2. Third-party imports second
14+
3. Local module imports last
15+
4. Each group alphabetically sorted
16+
5. Use `from typing import` for type hints
17+
18+
Example:
19+
```python
20+
import datetime
21+
import logging
22+
import random
23+
from typing import List, Optional, Set, Dict, Any
24+
25+
from nicegui import ui, app
26+
27+
from src.config.constants import HEADER_TEXT
28+
from src.types.ui_types import BoardType
29+
```
30+
31+
### Naming Conventions
32+
- **Functions/Variables**: `snake_case`
33+
- **Constants**: `UPPER_CASE` (defined at top of file)
34+
- **Classes**: `PascalCase`
35+
- **Type Aliases**: `PascalCase`
36+
- **Private Methods**: `_leading_underscore`
37+
38+
### Type Hints
39+
- Use type hints for all function signatures
40+
- Use `Optional[T]` for nullable types
41+
- Use `List`, `Dict`, `Set`, `Tuple` from typing
42+
- Define custom types in `src/types/`
43+
44+
### Documentation
45+
- Triple-quoted docstrings for modules and functions
46+
- Brief description at module level
47+
- No inline comments unless absolutely necessary
48+
- Descriptive variable/function names over comments
49+
50+
### Error Handling
51+
- Use try/except blocks with specific exceptions
52+
- Log errors using the logging module
53+
- Provide meaningful error messages
54+
55+
### NiceGUI Specific
56+
- Define UI element styling as class constants
57+
- Use context managers for UI containers
58+
- Separate UI logic from business logic
59+
- Handle disconnected clients gracefully
60+
61+
### Code Organization
62+
- Keep functions focused and single-purpose
63+
- Extract constants to config module
64+
- Separate concerns into appropriate modules
65+
- Use type definitions for complex data structures
66+
67+
### Testing Conventions
68+
- Test files: `test_*.py`
69+
- Test classes: `Test*`
70+
- Test functions: `test_*`
71+
- Use pytest fixtures for setup
72+
- Mock external dependencies
73+
- Aim for high test coverage
74+
75+
## Formatting Tools
76+
- **Black**: Automatic code formatting
77+
- **isort**: Import sorting with Black compatibility
78+
- **flake8**: Linting (configured for 88 char lines)
79+
- **mypy**: Static type checking
80+
81+
All formatting is automated via `make format` or individual Poetry commands.

‎.serena/memories/git_history_insights.md‎

Lines changed: 44 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,44 @@
1+
# Bingo Project - Git History Insights
2+
3+
## Recent Development (March 2025)
4+
- Latest commit: `da9cde7` - feat: persist state (main branch)
5+
- Feature branch exists: `feature/persisting-state` with WIP changes
6+
- Author: Jonathan Irvin <[email protected]>
7+
8+
## Version History
9+
- Current version: v1.1.4 (released via semantic versioning)
10+
- Major milestones:
11+
- v1.0.0: Major release with semantic versioning established
12+
- v0.1.0: Initial modular architecture refactoring
13+
14+
## Key Development Patterns
15+
1. **Conventional Commits**: Strictly follows format (feat, fix, chore, docs, test, refactor)
16+
2. **Automated Releases**: Uses python-semantic-release with [skip ci] tags
17+
3. **PR-based Workflow**: Features developed in branches, merged via PRs
18+
4. **Code Quality**: Every PR includes formatting (black, isort) and testing
19+
20+
## Recent Changes (v1.1.4)
21+
- State persistence implementation (March 16, 2025)
22+
- Health check improvements with JSON formatting
23+
- Import sorting and formatting fixes
24+
- Added comprehensive state persistence tests (459 lines)
25+
- Enhanced board builder tests (257 lines)
26+
27+
## Architecture Evolution Timeline
28+
1. Initial monolithic `main.py` implementation
29+
2. Modular refactoring (v0.1.0) - split into src/ structure
30+
3. UI improvements - closed game message display
31+
4. NiceGUI 2.11+ compatibility fixes
32+
5. State persistence across app restarts (latest)
33+
34+
## Testing Evolution
35+
- Started with basic tests
36+
- Added comprehensive unit tests (80% coverage)
37+
- Latest: Extensive state persistence testing
38+
- Focus on UI synchronization and user tracking
39+
40+
## CI/CD Pipeline
41+
- GitHub Actions for automated testing and releases
42+
- Disabled Docker and Helm workflows (kept as reference)
43+
- Semantic versioning based on commit messages
44+
- Automatic CHANGELOG.md updates

‎.serena/memories/incomplete_branch_strategy.md‎

Lines changed: 111 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,111 @@
1+
# Strategy for Handling Incomplete Remote Branches
2+
3+
## Overview
4+
When returning to a project with incomplete work in remote branches, a systematic approach helps assess and decide how to proceed with each branch.
5+
6+
## Discovery Commands
7+
```bash
8+
# List all branches
9+
git branch -a
10+
11+
# Find unmerged branches
12+
git branch --no-merged main
13+
14+
# Recent branch activity
15+
git for-each-ref --sort=-committerdate refs/remotes/origin --format='%(committerdate:short) %(refname:short) %(subject)'
16+
17+
# Check specific branch differences
18+
git log main..origin/branch-name --oneline
19+
git diff main...origin/branch-name --stat
20+
```
21+
22+
## Decision Framework
23+
24+
### 1. Create Draft PR
25+
**When**: Work is partially complete but needs visibility
26+
```bash
27+
gh pr create --draft --base main --head branch-name --title "WIP: Description"
28+
```
29+
**Benefits**:
30+
- Documents intent and approach
31+
- Allows collaboration
32+
- Preserves context
33+
- Shows in PR list for tracking
34+
35+
### 2. Local Continuation
36+
**When**: Work is experimental or very incomplete
37+
```bash
38+
git checkout branch-name
39+
git pull origin branch-name
40+
# Option A: Continue directly
41+
# Option B: Stash current state first
42+
git stash push -m "Previous WIP attempt"
43+
```
44+
45+
### 3. Rebase and Cleanup
46+
**When**: Commits need reorganization before review
47+
```bash
48+
git checkout branch-name
49+
git rebase -i main
50+
# Clean up commit history
51+
```
52+
53+
### 4. Extract Useful Parts
54+
**When**: Some ideas are good but implementation needs restart
55+
```bash
56+
# Cherry-pick specific commits
57+
git cherry-pick commit-hash
58+
59+
# Or create patches
60+
git format-patch main..branch-name
61+
```
62+
63+
## Best Practices
64+
65+
1. **Use Git Worktrees** for isolated testing:
66+
```bash
67+
git worktree add ../project-wip branch-name
68+
```
69+
70+
2. **Document Intent**:
71+
- Check commit messages for TODOs
72+
- Look for related issues
73+
- Add comments to draft PRs
74+
75+
3. **Test Before Deciding**:
76+
```bash
77+
poetry install
78+
poetry run pytest
79+
poetry run flake8
80+
```
81+
82+
4. **Communicate Status**:
83+
- Update PR descriptions
84+
- Close stale branches
85+
- Document decisions
86+
87+
## Handling "WIP and Broken" Commits
88+
89+
1. First understand what's broken:
90+
- Run tests to see failures
91+
- Check linting errors
92+
- Try running the application
93+
94+
2. Decide on approach:
95+
- Fix and continue if close to working
96+
- Extract concepts if fundamentally flawed
97+
- Archive with explanation if obsolete
98+
99+
3. Clean up before merging:
100+
- Squash WIP commits
101+
- Write proper commit messages
102+
- Ensure all tests pass
103+
104+
## Branch Lifecycle Management
105+
106+
- **Active**: Currently being developed
107+
- **Draft PR**: Under review/discussion
108+
- **Stale**: No activity >30 days
109+
- **Archived**: Kept for reference but not active
110+
111+
Regular cleanup prevents accumulation of dead branches while preserving useful experimental work.

‎.serena/memories/nicegui_storage_architecture_findings.md‎

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
# NiceGUI Storage Architecture Findings
2+
3+
## Key Discoveries from Documentation
4+
5+
### 1. Application Lifecycle
6+
- NiceGUI apps start with `ui.run()` which launches the web server
7+
- The app uses FastAPI/Starlette underneath with Uvicorn as the ASGI server
8+
- Frontend uses Vue.js, Quasar, and Tailwind CSS
9+
10+
### 2. Storage Implementation Details
11+
From the documentation analysis:
12+
- No explicit mention of `app.storage.general` being client-side localStorage
13+
- Storage appears to be a NiceGUI abstraction but implementation details not clear
14+
- The framework focuses on reactive UI elements, not persistent storage
15+
16+
### 3. Server Architecture
17+
- Built on top of FastAPI (ASGI framework)
18+
- Uses WebSocket connections for real-time updates
19+
- Docker deployment is well-supported
20+
- Can run behind reverse proxies (nginx examples provided)
21+
22+
### 4. Missing Information
23+
The documentation doesn't clearly explain:
24+
- Whether `app.storage` is server-side or client-side
25+
- How storage persists across server restarts
26+
- Best practices for state persistence
27+
- Lifecycle hooks for initialization
28+
29+
## Implications for Our Issue
30+
31+
1. **Storage Type Unclear**: The docs don't confirm if `app.storage.general` is browser localStorage or server-side storage
32+
33+
2. **No State Persistence Examples**: No examples show persisting game state across server restarts
34+
35+
3. **Docker/Production Focus**: Examples focus on deployment but not on state management
36+
37+
4. **Testing Approach**: The testing framework uses a `Screen` class for UI testing, not state persistence testing
38+
39+
## Recommended Architecture Based on Findings
40+
41+
Since NiceGUI documentation doesn't provide clear guidance on persistent storage:
42+
43+
1. **Assume Client-Side**: Treat `app.storage.general` as client-side until proven otherwise
44+
2. **Implement Server-Side**: Create our own server-side persistence layer
45+
3. **Use FastAPI Features**: Leverage the underlying FastAPI for lifecycle management
46+
4. **File/DB Storage**: Implement file or database storage independent of NiceGUI
47+
48+
## Next Steps
49+
50+
1. Test if `app.storage.general` survives server restarts (empirical testing)
51+
2. Implement server-side storage solution (file or SQLite)
52+
3. Use FastAPI lifecycle events for initialization
53+
4. Create proper state management layer

0 commit comments

Comments
 (0)