personal-projects/gitea-mcp-remote
1
0
Fork 0
generated from personal-projects/leo-claude-mktplace
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

[Sprint 02] test: Create test suite for wrapper functionality #17

New Issue
Closed
opened 2026-02-03 21:02:45 +00:00 by lmiranda · 1 comment
lmiranda commented 2026-02-03 21:02:45 +00:00
Owner
Copy Link

Summary

Create a new test suite for the wrapper components (tool_filter, auth, server_http). Do NOT test marketplace tools (already tested upstream).

Tasks

Test Structure

  • Create tests/ directory
  • Create tests/__init__.py
  • Create tests/conftest.py with shared fixtures
  • Add pytest and pytest-asyncio to dev dependencies

test_tool_filter.py

  • Test allowlist filtering (only allowed tools returned)
  • Test denylist filtering (denied tools excluded)
  • Test precedence (allowlist beats denylist)
  • Test no filtering (all tools returned)
  • Test edge cases (empty lists, invalid tool names)
  • Mock tools with Tool objects from MCP

test_auth.py

  • Test Bearer token validation (valid token passes)
  • Test invalid token returns 401
  • Test missing Authorization header returns 401
  • Test no-auth mode (AUTH_TOKEN unset)
  • Test malformed Authorization header
  • Mock HTTP requests with proper headers

test_server_http.py

  • Test server initialization
  • Test config loading
  • Test marketplace tool import (mock the import)
  • Test tool filtering integration
  • Test auth middleware integration
  • Test HTTP endpoint responses
  • Mock GiteaClient from marketplace

Test Configuration

  • Create pytest.ini or pyproject.toml test config
  • Set up coverage reporting (pytest-cov)
  • Target >80% coverage for wrapper code
  • Add test running instructions to README

Acceptance Criteria

  • All three test files exist and pass
  • pytest runs without errors
  • Coverage report shows >80% for wrapper modules
  • Tests use proper mocking (no real API calls)
  • Tests are fast (no network I/O)
  • Tests are isolated (no shared state)
  • CI-ready (can run in Docker or GitHub Actions)

Dependencies

Blocked by: #14 (server must exist to test)

Context

These tests validate the wrapper logic only. The marketplace tools have their own tests upstream. Focus on: config, filtering, auth, and HTTP transport.

References:

  • Corrective Rebuild specification
  • Step 14 of 14-step rebuild plan

Size: M (4-5 hours)

## Summary Create a new test suite for the wrapper components (tool_filter, auth, server_http). Do NOT test marketplace tools (already tested upstream). ## Tasks ### Test Structure - [ ] Create `tests/` directory - [ ] Create `tests/__init__.py` - [ ] Create `tests/conftest.py` with shared fixtures - [ ] Add pytest and pytest-asyncio to dev dependencies ### test_tool_filter.py - [ ] Test allowlist filtering (only allowed tools returned) - [ ] Test denylist filtering (denied tools excluded) - [ ] Test precedence (allowlist beats denylist) - [ ] Test no filtering (all tools returned) - [ ] Test edge cases (empty lists, invalid tool names) - [ ] Mock tools with `Tool` objects from MCP ### test_auth.py - [ ] Test Bearer token validation (valid token passes) - [ ] Test invalid token returns 401 - [ ] Test missing Authorization header returns 401 - [ ] Test no-auth mode (AUTH_TOKEN unset) - [ ] Test malformed Authorization header - [ ] Mock HTTP requests with proper headers ### test_server_http.py - [ ] Test server initialization - [ ] Test config loading - [ ] Test marketplace tool import (mock the import) - [ ] Test tool filtering integration - [ ] Test auth middleware integration - [ ] Test HTTP endpoint responses - [ ] Mock GiteaClient from marketplace ### Test Configuration - [ ] Create `pytest.ini` or `pyproject.toml` test config - [ ] Set up coverage reporting (pytest-cov) - [ ] Target >80% coverage for wrapper code - [ ] Add test running instructions to README ## Acceptance Criteria - All three test files exist and pass - `pytest` runs without errors - Coverage report shows >80% for wrapper modules - Tests use proper mocking (no real API calls) - Tests are fast (no network I/O) - Tests are isolated (no shared state) - CI-ready (can run in Docker or GitHub Actions) ## Dependencies **Blocked by:** #14 (server must exist to test) ## Context These tests validate the wrapper logic only. The marketplace tools have their own tests upstream. Focus on: config, filtering, auth, and HTTP transport. **References:** - Corrective Rebuild specification - Step 14 of 14-step rebuild plan **Size:** M (4-5 hours)
lmiranda added this to the Sprint 02: Corrective Rebuild milestone 2026-02-03 21:02:45 +00:00
lmiranda added the Component/TestingType/TestTech/PythonSize/MPriority/High labels 2026-02-03 21:02:45 +00:00
lmiranda commented 2026-02-03 21:02:49 +00:00
Author
Owner
Copy Link

⚠️ Blocked By: #14

⚠️ **Blocked By:** #14
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Component/API
API endpoints, contracts, and integration
 Component/Auth
Authentication and authorization
 Component/Backend
Backend/server-side code
 Component/Backend
Backend service code and business logic
 Component/Core
Core application logic and architecture
 Component/Database
Database schemas, migrations, queries
 Component/Dependencies
Package dependencies and requirements
 Component/Deploy
Deployment, infrastructure, DevOps
 Component/Docker
Docker and containerization
 Component/Docs
Documentation and guides
 Component/Documentation
Documentation and guides
 Component/Frontend
User interface and client-side code
 Component/Infra
Infrastructure and system configuration
 Component/Integration
Integration and end-to-end testing
 Component/Testing
Test infrastructure and frameworks
 Priority/Critical
Critical priority - blocks other work
 Priority/High
High priority items
 Priority/Medium
Medium priority items
 Size/L
Large task (4-8 hours)
 Size/M
Medium task (2-4 hours)
 Size/S
Small task (1-2 hours)
 Tech/Docker
Docker containers and compose
 Tech/FastAPI
FastAPI backend framework
 Tech/JavaScript
JavaScript/Node.js code
 Tech/PostgreSQL
PostgreSQL database
 Tech/Python
Python language and libraries
 Tech/Redis
Redis cache and pub/sub
 Tech/Vue
Vue.js frontend framework
 Type/Build
Build system and dependencies
 Type/Documentation
Documentation updates
 Type/Feature
New feature implementation
 Type/Refactor
Code refactoring and restructuring
 Type/Setup
Initial project setup tasks
 Type/Test
Testing and quality assurance
Complexity/Complex
High uncertainty or many dependencies
 Complexity/Medium
Some unknowns or dependencies
 Complexity/Simple
Straightforward, well-understood
 Effort/L
3-5 days
 Effort/M
1-2 days
 Effort/S
2-4 hours
 Effort/XL
> 1 week
 Effort/XS
< 2 hours
 Priority/Critical
Immediate attention required
 Priority/High
Important, needs attention soon
 Priority/Low
Nice to have, can wait
 Priority/Medium
Normal priority
 Type/Bug
Something isn't working
 Type/Chore
Maintenance tasks
 Type/Documentation
Documentation improvements
 Type/Feature
New feature or request
 Type/Refactor
Code refactoring without changing behavior
 Type/Test
Testing related
No Label Component/Testing Priority/High Size/M Tech/Python Type/Test
Milestone
No items
No Milestone Sprint 02: Corrective Rebuild
Projects
Clear projects
No project
Assignees
Clear assignees
lmiranda
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: personal-projects/gitea-mcp-remote#17
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?