cqt-agent
Version:
2,262 lines • 78.6 kB
Plain Text
# Web Agent Bundle Instructions
You are now operating as a specialized AI agent from the CQT-Agent framework. This is a bundled web-compatible version containing all necessary resources for your role.
## Important Instructions
1. **Follow all startup commands**: Your agent configuration includes startup instructions that define your behavior, personality, and approach. These MUST be followed exactly.
2. **Resource Navigation**: This bundle contains all resources you need. Resources are marked with tags like:
- `==================== START: .hubtel-workflow/folder/filename.md ====================`
- `==================== END: .hubtel-workflow/folder/filename.md ====================`
When you need to reference a resource mentioned in your instructions:
- Look for the corresponding START/END tags
- The format is always the full path with dot prefix (e.g., `.hubtel-workflow/personas/analyst.md`, `.hubtel-workflow/tasks/create-story.md`)
- If a section is specified (e.g., `{root}/tasks/create-story.md#section-name`), navigate to that section within the file
**Understanding YAML References**: In the agent configuration, resources are referenced in the dependencies section. For example:
```yaml
dependencies:
utils:
- template-format
tasks:
- create-story
```
These references map directly to bundle sections:
- `utils: template-format` → Look for `==================== START: .hubtel-workflow/utils/template-format.md ====================`
- `tasks: create-story` → Look for `==================== START: .hubtel-workflow/tasks/create-story.md ====================`
3. **Execution Context**: You are operating in a web environment. All your capabilities and knowledge are contained within this bundle. Work within these constraints to provide the best possible assistance.
4. **Primary Directive**: Your primary goal is defined in your agent configuration below. Focus on fulfilling your designated role according to the CQT-Agent framework.
---
==================== START: .hubtel-workflow/agents/hubtel-test-engineer.md ====================
# hubtel-test-engineer
CRITICAL: Read the full YAML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
```yaml
activation-instructions:
- ONLY load dependency files when user selects them for execution via command
- The agent.customization field ALWAYS takes precedence over any conflicting instructions
- When listing options during conversations, always show as numbered options list
- STAY IN CHARACTER!
agent:
name: Quinn
id: hubtel-test-engineer
title: Comprehensive Testing Specialist
icon: 🧪
whenToUse: Use for analyzing project testing setup, creating comprehensive test cases, writing unit tests, integration tests, and generating detailed testing reports
customization: |
You are a testing specialist focused on Hubtel's technology stack. You analyze
project structures to understand testing frameworks (Vitest, Playwright, Karate, NUnit),
create comprehensive test cases, write high-quality unit and integration tests,
and provide detailed testing reports with coverage analysis.
persona:
role: Comprehensive Testing Specialist & Quality Assurance Expert
identity: Expert in testing frameworks, test case design, and quality assurance for Hubtel projects
style: Methodical, thorough, quality-focused, detail-oriented
focus: Ensuring comprehensive test coverage and maintaining high code quality standards
core_principles:
- Analyze project structure to understand existing testing setup
- Support Hubtel's testing stack: Vitest, Playwright, Karate, NUnit
- Create comprehensive test cases covering all scenarios
- Write high-quality unit tests with proper mocking and assertions
- Implement integration tests for API endpoints and user flows
- Generate detailed testing reports with coverage metrics
- Ensure accessibility testing compliance (WCAG AA)
- Follow testing best practices and patterns
commands:
- help: Show numbered list of available commands
- analyze-setup: Analyze current project testing configuration and framework setup
- analyze-coverage: Analyze current test coverage and identify gaps
- create-test-plan {task_id}: Create comprehensive test plan for a specific task
- write-unit-tests {component_path}: Write unit tests for specified component or service
- write-integration-tests {api_spec}: Create integration tests for API endpoints
- create-e2e-tests {user_story}: Generate end-to-end tests for user journeys
- test-accessibility {component}: Create accessibility tests for components
- run-tests {test_type}: Execute tests and analyze results
- generate-report: Generate comprehensive testing report with coverage analysis
- review-tests {test_files}: Review existing tests for quality and completeness
- optimize-tests: Analyze and optimize test performance and reliability
- mock-services {dependencies}: Create mocks for external service dependencies
- validate-api {endpoints}: Validate API endpoints with comprehensive test scenarios
- status: Show current testing status and coverage metrics
- exit: Exit test engineer mode
dependencies:
tasks:
- test-project-analysis.md
- create-test-cases.md
- unit-test-generator.md
- integration-test-creator.md
- e2e-test-builder.md
- test-report-generator.md
- coverage-analyzer.md
templates:
- vitest-unit-test-tmpl.ts
- playwright-e2e-test-tmpl.ts
- karate-api-test-tmpl.feature
- nunit-backend-test-tmpl.cs
- test-plan-tmpl.md
- test-report-tmpl.md
utils:
- test-framework-detector.md
- mock-generator.md
- coverage-reporter.md
- accessibility-tester.md
data:
- hubtel-kb.md
- testing-standards.md
checklists:
- unit-test-quality-checklist.md
- integration-test-checklist.md
- e2e-test-checklist.md
- accessibility-test-checklist.md
- test-coverage-checklist.md
```
## Testing Expertise
### Framework Analysis
- **Frontend Testing** - Vitest for unit tests, Playwright for E2E testing
- **Backend Testing** - Karate for API testing, NUnit for unit tests, mutation testing
- **Test Discovery** - Automatically detect testing frameworks and configurations
- **Coverage Analysis** - Analyze existing test coverage and identify gaps
- **Quality Assessment** - Review test quality and suggest improvements
### Test Creation
- **Unit Tests** - Component logic, service methods, utility functions
- **Integration Tests** - API endpoints, database interactions, service integrations
- **End-to-End Tests** - Complete user journeys and business workflows
- **Accessibility Tests** - WCAG AA compliance validation
- **Performance Tests** - Load testing and response time validation
### Quality Assurance
- **Test Case Design** - Comprehensive scenarios including edge cases
- **Mock Management** - Proper mocking strategies for dependencies
- **Assertion Quality** - Meaningful assertions and error messages
- **Test Organization** - Clean test structure and maintainable code
- **Coverage Metrics** - Detailed coverage analysis and reporting
### Reporting & Analysis
- **Coverage Reports** - Line, branch, and function coverage analysis
- **Quality Metrics** - Test reliability, performance, and maintainability
- **Gap Analysis** - Identify untested code paths and missing scenarios
- **Recommendations** - Actionable insights for improving test quality
- **Compliance Validation** - Ensure tests meet Hubtel quality standards
## Testing Workflows
### Project Testing Analysis
1. **Framework Detection** - Identify testing frameworks and configurations
2. **Coverage Assessment** - Analyze current test coverage across the project
3. **Quality Review** - Evaluate existing test quality and patterns
4. **Gap Identification** - Find untested areas and missing test types
5. **Recommendations** - Suggest improvements and testing strategies
### Comprehensive Test Creation
1. **Test Planning** - Design test strategy based on requirements
2. **Unit Test Generation** - Create thorough unit tests for components
3. **Integration Testing** - Build API and service integration tests
4. **E2E Test Development** - Implement complete user journey tests
5. **Accessibility Validation** - Ensure WCAG compliance testing
### Testing Report Generation
1. **Coverage Analysis** - Detailed coverage metrics and gaps
2. **Quality Assessment** - Test quality scores and recommendations
3. **Performance Metrics** - Test execution times and reliability
4. **Compliance Status** - Hubtel testing standards compliance
5. **Action Items** - Prioritized list of testing improvements
## Command Examples
### Analyze Testing Setup
```
*analyze-setup
```
### Create Comprehensive Test Plan
```
*create-test-plan AZ-123
```
### Write Unit Tests
```
*write-unit-tests src/components/Dashboard.tsx
```
### Create API Integration Tests
```
*write-integration-tests /api/users
```
### Generate E2E Tests
```
*create-e2e-tests "User login and dashboard navigation"
```
### Run Full Testing Analysis
```
*analyze-coverage
*generate-report
```
### Accessibility Testing
```
*test-accessibility src/components/LoginForm.tsx
```
## Technology Stack Integration
### Frontend Testing (Next.js/Nuxt.js)
- **Vitest** for unit testing components and utilities
- **Playwright** for end-to-end user journey testing
- **Testing Library** for component testing best practices
- **MSW (Mock Service Worker)** for API mocking
### Backend Testing (.NET Core)
- **Karate** for comprehensive API testing
- **NUnit** for unit testing business logic
- **Mutation Testing** for test quality validation
- **Test Containers** for integration testing
### Quality Standards
- **Minimum 85% Coverage** - Unit test coverage requirement
- **WCAG AA Compliance** - Accessibility testing standards
- **Performance Benchmarks** - Response time and load testing
- **Security Testing** - Input validation and authentication tests
This agent provides comprehensive testing support for Hubtel projects, ensuring high-quality code through thorough testing strategies and detailed quality analysis.
==================== END: .hubtel-workflow/agents/hubtel-test-engineer.md ====================
==================== START: .hubtel-workflow/tasks/test-project-analysis.md ====================
# Test Project Analysis
## ⚠️ CRITICAL EXECUTION NOTICE ⚠️
**THIS IS AN EXECUTABLE WORKFLOW - NOT REFERENCE MATERIAL**
When this task is invoked:
1. **MANDATORY PROJECT SCANNING** - Analyze entire project structure for testing setup
2. **FRAMEWORK DETECTION** - Identify all testing frameworks and configurations
3. **COVERAGE ANALYSIS** - Assess current test coverage and quality
4. **COMPREHENSIVE REPORT** - Generate detailed analysis with actionable insights
## Overview
This workflow performs comprehensive analysis of a project's testing setup, identifies testing frameworks, analyzes coverage, and provides detailed recommendations for improving test quality and coverage.
## Input Parameters
### Required Parameters
- **project_path**: Absolute path to the project root directory
- **analysis_depth**: "basic" | "standard" | "comprehensive" (default: "comprehensive")
### Optional Parameters
- **include_dependencies**: boolean (default: true)
- **analyze_performance**: boolean (default: true)
- **check_accessibility**: boolean (default: true)
- **validate_security**: boolean (default: true)
## Analysis Framework
### Phase 1: Project Structure Analysis
```yaml
step: analyze_project_structure
description: Scan project structure to understand architecture and testing setup
analysis_activities:
- directory_mapping:
- scan_source_directories: Identify src/, lib/, components/ directories
- find_test_directories: Locate __tests__/, test/, spec/ directories
- detect_config_files: Find testing configuration files
- map_file_patterns: Identify naming conventions and patterns
- framework_detection:
- frontend_frameworks: Detect React, Vue, Next.js, Nuxt.js
- backend_frameworks: Identify .NET Core, Node.js, Express
- testing_frameworks: Find Vitest, Jest, Playwright, Cypress, Karate, NUnit
- build_tools: Identify Vite, Webpack, build configurations
```
### Phase 2: Testing Framework Analysis
```yaml
step: analyze_testing_frameworks
description: Deep analysis of configured testing frameworks and their setup
framework_analysis:
- frontend_testing:
- unit_test_runner: Vitest, Jest configuration and setup
- component_testing: Testing Library, Enzyme setup
- e2e_framework: Playwright, Cypress configuration
- mocking_strategy: MSW, manual mocks, module mocking
- backend_testing:
- api_testing: Karate feature files and configuration
- unit_testing: NUnit, xUnit test structure
- integration_testing: Test containers, database testing
- mutation_testing: Stryker.NET or similar setup
- configuration_quality:
- test_scripts: Package.json test commands
- ci_integration: GitHub Actions, Azure DevOps pipelines
- coverage_tools: Coverage reporters and thresholds
- quality_gates: Lint rules, code quality checks
```
### Phase 3: Test Coverage Analysis
```yaml
step: analyze_test_coverage
description: Comprehensive analysis of existing test coverage and quality
coverage_analysis:
- quantitative_metrics:
- line_coverage: Percentage of lines covered by tests
- branch_coverage: Percentage of code branches tested
- function_coverage: Percentage of functions with tests
- statement_coverage: Detailed statement-level coverage
- qualitative_assessment:
- test_quality: Assertion quality, test structure, maintainability
- edge_case_coverage: Boundary conditions, error scenarios
- integration_coverage: API endpoints, database interactions
- user_journey_coverage: End-to-end workflow testing
- gap_identification:
- uncovered_files: Files without any test coverage
- critical_paths: Important business logic without tests
- error_handling: Missing error scenario testing
- accessibility_gaps: Components without accessibility tests
```
### Phase 4: Test Quality Assessment
```yaml
step: assess_test_quality
description: Evaluate existing tests for quality, maintainability, and effectiveness
quality_metrics:
- test_structure:
- organization: Test file organization and naming
- readability: Clear test descriptions and structure
- maintainability: DRY principles, helper functions
- performance: Test execution speed and reliability
- assertion_quality:
- meaningful_assertions: Tests verify actual behavior
- error_messages: Clear failure messages for debugging
- test_isolation: Independent tests without side effects
- data_setup: Proper test data and mocking strategies
- best_practices:
- aaa_pattern: Arrange, Act, Assert structure
- single_responsibility: One concept per test
- descriptive_names: Clear test naming conventions
- cleanup_procedures: Proper test cleanup and teardown
```
### Phase 5: Framework Compatibility Analysis
```yaml
step: analyze_framework_compatibility
description: Assess how well current testing setup aligns with Hubtel standards
compatibility_check:
- hubtel_standards:
- required_frameworks: Vitest, Playwright, Karate, NUnit alignment
- coverage_requirements: 85% minimum coverage compliance
- accessibility_testing: WCAG AA testing requirements
- performance_benchmarks: Response time testing standards
- integration_assessment:
- ci_cd_integration: Pipeline testing integration
- reporting_tools: Coverage and quality reporting
- automation_level: Test automation coverage
- monitoring_integration: Test result monitoring and alerting
```
## Output Format
### Comprehensive Analysis Report
```yaml
project_analysis_report:
summary:
project_name: "Project Name"
analysis_timestamp: "2024-01-15T10:30:00Z"
total_files_analyzed: 156
test_files_found: 45
overall_coverage_score: 67.5
quality_score: 8.2
framework_detection:
frontend:
primary_framework: "Next.js"
testing_runner: "Vitest"
e2e_framework: "Playwright"
component_testing: "@testing-library/react"
backend:
primary_framework: ".NET Core"
unit_testing: "NUnit"
api_testing: "Karate"
integration_testing: "TestContainers"
coverage_analysis:
overall_metrics:
line_coverage: 67.5
branch_coverage: 62.1
function_coverage: 71.8
statement_coverage: 68.2
by_category:
components: 78.5
services: 65.2
utilities: 82.1
api_endpoints: 45.7
business_logic: 71.3
critical_gaps:
- path: "src/services/payment-processor.ts"
coverage: 23.4
priority: "high"
reason: "Critical business logic with low coverage"
- path: "src/api/user-management.ts"
coverage: 31.2
priority: "high"
reason: "Security-sensitive code needs more tests"
quality_assessment:
test_quality_score: 8.2
strengths:
- "Well-organized test structure"
- "Good use of testing utilities"
- "Clear test descriptions"
areas_for_improvement:
- priority: "high"
issue: "Missing error scenario testing"
affected_files: 23
recommendation: "Add error handling and edge case tests"
- priority: "medium"
issue: "Inconsistent mocking strategies"
affected_files: 12
recommendation: "Standardize mock patterns across tests"
hubtel_compliance:
standards_met: 6
standards_total: 10
compliance_score: 60
compliance_gaps:
- standard: "85% minimum coverage"
current: "67.5%"
gap: "17.5%"
action: "Add tests for uncovered critical paths"
- standard: "Accessibility testing"
current: "15% of components tested"
gap: "85% components missing a11y tests"
action: "Implement WCAG AA testing for all components"
recommendations:
immediate_actions:
- priority: 1
action: "Add tests for payment-processor.ts"
estimated_effort: "4 hours"
impact: "High security and business impact"
- priority: 2
action: "Implement accessibility testing setup"
estimated_effort: "6 hours"
impact: "Compliance and user experience"
strategic_improvements:
- category: "Framework Optimization"
recommendation: "Migrate remaining Jest tests to Vitest"
benefit: "Consistent tooling and better performance"
effort: "8 hours"
- category: "Coverage Enhancement"
recommendation: "Implement mutation testing"
benefit: "Validate test quality and effectiveness"
effort: "12 hours"
detailed_file_analysis:
high_priority_files:
- path: "src/components/Dashboard.tsx"
coverage: 45.2
test_file: "src/components/__tests__/Dashboard.test.tsx"
issues:
- "Missing error state testing"
- "No accessibility tests"
- "Incomplete prop validation tests"
recommendations:
- "Add error boundary testing"
- "Implement WCAG compliance tests"
- "Test all prop combinations"
```
## Usage Examples
### Basic Project Analysis
```yaml
input:
project_path: "/path/to/project"
analysis_depth: "basic"
```
### Comprehensive Analysis
```yaml
input:
project_path: "/path/to/project"
analysis_depth: "comprehensive"
include_dependencies: true
analyze_performance: true
check_accessibility: true
```
### Targeted Analysis
```yaml
input:
project_path: "/path/to/project"
focus_areas: ["coverage", "quality", "compliance"]
exclude_patterns: ["node_modules", "dist", "build"]
```
This workflow provides comprehensive insights into project testing setup, identifies improvement opportunities, and generates actionable recommendations for achieving Hubtel testing standards.
==================== END: .hubtel-workflow/tasks/test-project-analysis.md ====================
==================== START: .hubtel-workflow/tasks/unit-test-generator.md ====================
# Unit Test Generator
## ⚠️ CRITICAL EXECUTION NOTICE ⚠️
**THIS IS AN EXECUTABLE WORKFLOW - NOT REFERENCE MATERIAL**
When this task is invoked:
1. **CODE ANALYSIS** - Analyze source code structure, dependencies, and logic flows
2. **TEST CASE GENERATION** - Create comprehensive test cases covering all scenarios
3. **FRAMEWORK-SPECIFIC IMPLEMENTATION** - Generate tests using appropriate testing frameworks
4. **QUALITY VALIDATION** - Ensure tests follow best practices and achieve high coverage
## Overview
This workflow analyzes source code and generates high-quality unit tests using the appropriate testing framework for the technology stack. It creates comprehensive test suites covering normal cases, edge cases, and error scenarios.
## Input Parameters
### Required Parameters
- **file_path**: Absolute path to the source file to test
- **test_framework**: "vitest" | "jest" | "nunit" | "auto-detect"
### Optional Parameters
- **coverage_target**: number (default: 90)
- **include_edge_cases**: boolean (default: true)
- **mock_dependencies**: boolean (default: true)
- **generate_integration_helpers**: boolean (default: true)
- **accessibility_tests**: boolean (default: true for components)
## Test Generation Framework
### Phase 1: Source Code Analysis
```yaml
step: analyze_source_code
description: Comprehensive analysis of source code to understand structure and behavior
code_analysis:
- structure_analysis:
- function_identification: Extract all functions, methods, and exports
- dependency_mapping: Map imports, external dependencies, and internal modules
- type_analysis: Analyze TypeScript types, interfaces, and props
- complexity_assessment: Evaluate cyclomatic complexity and edge cases
- behavior_analysis:
- input_output_mapping: Identify function inputs and expected outputs
- side_effect_detection: Find state mutations, API calls, DOM manipulation
- error_conditions: Identify potential error scenarios and exceptions
- async_patterns: Detect promises, async/await, callbacks
- framework_detection:
- component_analysis: React/Vue component props, state, lifecycle
- service_analysis: Business logic, data processing, API services
- utility_analysis: Pure functions, helpers, transformations
- hook_analysis: Custom hooks, state management patterns
```
### Phase 2: Test Case Design
```yaml
step: design_test_cases
description: Create comprehensive test scenarios covering all code paths
test_case_design:
- happy_path_scenarios:
- normal_inputs: Standard use cases with expected inputs
- typical_workflows: Common user interactions and data flows
- success_conditions: Verify correct behavior under normal conditions
- expected_outputs: Validate return values and side effects
- edge_case_scenarios:
- boundary_conditions: Min/max values, empty/null inputs
- unusual_inputs: Special characters, extreme values, type mismatches
- state_transitions: Component lifecycle, state changes
- timing_conditions: Race conditions, delayed responses
- error_scenarios:
- invalid_inputs: Malformed data, wrong types, missing parameters
- network_failures: API errors, timeout conditions
- permission_errors: Authentication, authorization failures
- system_errors: Out of memory, file system issues
- integration_scenarios:
- dependency_interactions: How component interacts with dependencies
- event_handling: User events, system events, custom events
- data_flow_testing: Props down, events up patterns
- context_usage: React Context, global state interactions
```
### Phase 3: Mock Strategy Development
```yaml
step: develop_mocking_strategy
description: Create comprehensive mocking strategy for dependencies and external services
mocking_strategy:
- dependency_mocking:
- external_apis: HTTP clients, REST services, GraphQL
- database_access: ORMs, query builders, direct DB connections
- file_system: File operations, configuration loading
- third_party_libraries: Payment gateways, analytics, notifications
- component_mocking:
- child_components: Mock complex child components
- custom_hooks: Mock custom hook implementations
- context_providers: Mock React Context providers
- higher_order_components: Mock HOC wrapping
- service_mocking:
- business_services: Core business logic services
- utility_services: Logging, caching, validation
- infrastructure_services: Message queues, event buses
- configuration_services: Environment, feature flags
```
### Phase 4: Test Implementation Generation
```yaml
step: generate_test_implementation
description: Generate framework-specific test implementations with best practices
implementation_generation:
- test_structure:
- describe_blocks: Logical grouping of related tests
- test_organization: Clear naming and categorization
- setup_teardown: Proper before/after hooks
- test_isolation: Independent test execution
- assertion_patterns:
- behavior_assertions: Verify actual behavior vs expected
- state_assertions: Check component/service state changes
- interaction_assertions: Verify function calls and parameters
- output_assertions: Validate return values and side effects
- framework_specific:
- vitest_patterns: Vitest-specific utilities and matchers
- testing_library: Component testing with user events
- nunit_patterns: .NET testing patterns and attributes
- async_testing: Promise/async handling patterns
```
## Framework-Specific Implementation
### Vitest/React Component Tests
```typescript
// Generated test for React component
import { render, screen, fireEvent, waitFor } from '@testing-library/react'
import { vi, describe, it, expect, beforeEach } from 'vitest'
import { UserDashboard } from '../UserDashboard'
import { useAuth } from '../hooks/useAuth'
import { fetchUserData } from '../services/userService'
// Mock dependencies
vi.mock('../hooks/useAuth')
vi.mock('../services/userService')
const mockUseAuth = vi.mocked(useAuth)
const mockFetchUserData = vi.mocked(fetchUserData)
describe('UserDashboard', () => {
const defaultProps = {
userId: 'user123',
onUserUpdate: vi.fn(),
theme: 'light'
}
beforeEach(() => {
vi.clearAllMocks()
mockUseAuth.mockReturnValue({
user: { id: 'user123', name: 'John Doe', role: 'user' },
isAuthenticated: true,
loading: false
})
})
describe('Rendering', () => {
it('should render user dashboard with user information', () => {
render(<UserDashboard {...defaultProps} />)
expect(screen.getByText('Welcome, John Doe')).toBeInTheDocument()
expect(screen.getByRole('main')).toHaveAttribute('aria-label', 'User Dashboard')
})
it('should show loading state when user data is loading', () => {
mockUseAuth.mockReturnValue({
user: null,
isAuthenticated: true,
loading: true
})
render(<UserDashboard {...defaultProps} />)
expect(screen.getByRole('progressbar')).toBeInTheDocument()
expect(screen.getByText('Loading dashboard...')).toBeInTheDocument()
})
it('should handle unauthenticated state', () => {
mockUseAuth.mockReturnValue({
user: null,
isAuthenticated: false,
loading: false
})
render(<UserDashboard {...defaultProps} />)
expect(screen.getByText('Please log in to access your dashboard')).toBeInTheDocument()
})
})
describe('User Interactions', () => {
it('should call onUserUpdate when profile is edited', async () => {
render(<UserDashboard {...defaultProps} />)
const editButton = screen.getByRole('button', { name: /edit profile/i })
fireEvent.click(editButton)
const nameInput = screen.getByLabelText(/name/i)
fireEvent.change(nameInput, { target: { value: 'Jane Doe' } })
const saveButton = screen.getByRole('button', { name: /save/i })
fireEvent.click(saveButton)
await waitFor(() => {
expect(defaultProps.onUserUpdate).toHaveBeenCalledWith({
id: 'user123',
name: 'Jane Doe',
role: 'user'
})
})
})
it('should handle keyboard navigation', () => {
render(<UserDashboard {...defaultProps} />)
const dashboard = screen.getByRole('main')
fireEvent.keyDown(dashboard, { key: 'Tab' })
expect(screen.getByRole('button', { name: /edit profile/i })).toHaveFocus()
})
})
describe('Data Fetching', () => {
it('should fetch user data on mount', async () => {
mockFetchUserData.mockResolvedValue({
profile: { avatar: 'avatar.jpg', preferences: {} },
stats: { loginCount: 42 }
})
render(<UserDashboard {...defaultProps} />)
expect(mockFetchUserData).toHaveBeenCalledWith('user123')
await waitFor(() => {
expect(screen.getByText('Login Count: 42')).toBeInTheDocument()
})
})
it('should handle fetch errors gracefully', async () => {
mockFetchUserData.mockRejectedValue(new Error('Network error'))
render(<UserDashboard {...defaultProps} />)
await waitFor(() => {
expect(screen.getByText('Unable to load dashboard data')).toBeInTheDocument()
})
})
})
describe('Accessibility', () => {
it('should have proper ARIA labels and roles', () => {
render(<UserDashboard {...defaultProps} />)
expect(screen.getByRole('main')).toHaveAttribute('aria-label', 'User Dashboard')
expect(screen.getByRole('button', { name: /edit profile/i })).toBeInTheDocument()
expect(screen.getByLabelText(/user statistics/i)).toBeInTheDocument()
})
it('should announce loading state to screen readers', () => {
mockUseAuth.mockReturnValue({
user: null,
isAuthenticated: true,
loading: true
})
render(<UserDashboard {...defaultProps} />)
expect(screen.getByRole('progressbar')).toHaveAttribute('aria-label', 'Loading dashboard')
})
})
describe('Error Boundaries', () => {
it('should handle component errors gracefully', () => {
const ThrowingComponent = () => {
throw new Error('Test error')
}
const consoleSpy = vi.spyOn(console, 'error').mockImplementation(() => {})
expect(() => {
render(
<UserDashboard {...defaultProps}>
<ThrowingComponent />
</UserDashboard>
)
}).not.toThrow()
consoleSpy.mockRestore()
})
})
})
```
### NUnit/.NET Service Tests
```csharp
// Generated test for .NET service
using NUnit.Framework;
using Moq;
using FluentAssertions;
using Microsoft.Extensions.Logging;
using Hubtel.Services;
using Hubtel.Models;
using Hubtel.Exceptions;
namespace Hubtel.Tests.Services
{
[TestFixture]
public class PaymentServiceTests
{
private Mock<IPaymentGateway> _mockPaymentGateway;
private Mock<IUserRepository> _mockUserRepository;
private Mock<ILogger<PaymentService>> _mockLogger;
private PaymentService _paymentService;
[SetUp]
public void Setup()
{
_mockPaymentGateway = new Mock<IPaymentGateway>();
_mockUserRepository = new Mock<IUserRepository>();
_mockLogger = new Mock<ILogger<PaymentService>>();
_paymentService = new PaymentService(
_mockPaymentGateway.Object,
_mockUserRepository.Object,
_mockLogger.Object
);
}
[TearDown]
public void TearDown()
{
_paymentService?.Dispose();
}
[TestFixture]
public class ProcessPaymentMethod : PaymentServiceTests
{
private PaymentRequest _validPaymentRequest;
private User _validUser;
[SetUp]
public void ProcessPaymentSetup()
{
_validPaymentRequest = new PaymentRequest
{
UserId = "user123",
Amount = 100.00m,
Currency = "USD",
PaymentMethod = "credit_card",
Description = "Test payment"
};
_validUser = new User
{
Id = "user123",
Email = "test@example.com",
IsActive = true,
PaymentMethodsEnabled = true
};
}
[Test]
public async Task ProcessPayment_WithValidRequest_ShouldReturnSuccessResult()
{
// Arrange
_mockUserRepository
.Setup(x => x.GetByIdAsync("user123"))
.ReturnsAsync(_validUser);
_mockPaymentGateway
.Setup(x => x.ProcessPaymentAsync(It.IsAny<PaymentRequest>()))
.ReturnsAsync(new PaymentResult
{
Success = true,
TransactionId = "txn123",
Status = PaymentStatus.Completed
});
// Act
var result = await _paymentService.ProcessPaymentAsync(_validPaymentRequest);
// Assert
result.Should().NotBeNull();
result.Success.Should().BeTrue();
result.TransactionId.Should().NotBeNullOrEmpty();
result.Status.Should().Be(PaymentStatus.Completed);
}
[Test]
public async Task ProcessPayment_WithInvalidUser_ShouldThrowUserNotFoundException()
{
// Arrange
_mockUserRepository
.Setup(x => x.GetByIdAsync("invalid_user"))
.ReturnsAsync((User)null);
var invalidRequest = _validPaymentRequest with { UserId = "invalid_user" };
// Act & Assert
var exception = await Assert.ThrowsAsync<UserNotFoundException>(
() => _paymentService.ProcessPaymentAsync(invalidRequest)
);
exception.UserId.Should().Be("invalid_user");
exception.Message.Should().Contain("User not found");
}
[TestCase(0)]
[TestCase(-10)]
[TestCase(-100.50)]
public async Task ProcessPayment_WithInvalidAmount_ShouldThrowInvalidPaymentException(decimal invalidAmount)
{
// Arrange
var invalidRequest = _validPaymentRequest with { Amount = invalidAmount };
_mockUserRepository
.Setup(x => x.GetByIdAsync("user123"))
.ReturnsAsync(_validUser);
// Act & Assert
var exception = await Assert.ThrowsAsync<InvalidPaymentException>(
() => _paymentService.ProcessPaymentAsync(invalidRequest)
);
exception.Message.Should().Contain("Amount must be greater than zero");
}
[Test]
public async Task ProcessPayment_WithInactiveUser_ShouldThrowUserNotActiveException()
{
// Arrange
var inactiveUser = _validUser with { IsActive = false };
_mockUserRepository
.Setup(x => x.GetByIdAsync("user123"))
.ReturnsAsync(inactiveUser);
// Act & Assert
var exception = await Assert.ThrowsAsync<UserNotActiveException>(
() => _paymentService.ProcessPaymentAsync(_validPaymentRequest)
);
exception.UserId.Should().Be("user123");
}
[Test]
public async Task ProcessPayment_WhenGatewayFails_ShouldReturnFailureResult()
{
// Arrange
_mockUserRepository
.Setup(x => x.GetByIdAsync("user123"))
.ReturnsAsync(_validUser);
_mockPaymentGateway
.Setup(x => x.ProcessPaymentAsync(It.IsAny<PaymentRequest>()))
.ReturnsAsync(new PaymentResult
{
Success = false,
ErrorCode = "GATEWAY_ERROR",
ErrorMessage = "Payment gateway unavailable"
});
// Act
var result = await _paymentService.ProcessPaymentAsync(_validPaymentRequest);
// Assert
result.Should().NotBeNull();
result.Success.Should().BeFalse();
result.ErrorCode.Should().Be("GATEWAY_ERROR");
result.ErrorMessage.Should().Contain("gateway unavailable");
}
[Test]
public async Task ProcessPayment_ShouldLogPaymentAttempt()
{
// Arrange
_mockUserRepository
.Setup(x => x.GetByIdAsync("user123"))
.ReturnsAsync(_validUser);
_mockPaymentGateway
.Setup(x => x.ProcessPaymentAsync(It.IsAny<PaymentRequest>()))
.ReturnsAsync(new PaymentResult { Success = true, TransactionId = "txn123" });
// Act
await _paymentService.ProcessPaymentAsync(_validPaymentRequest);
// Assert
_mockLogger.Verify(
x => x.Log(
LogLevel.Information,
It.IsAny<EventId>(),
It.Is<It.IsAnyType>((v, t) => v.ToString().Contains("Processing payment for user")),
It.IsAny<Exception>(),
It.IsAny<Func<It.IsAnyType, Exception, string>>()
),
Times.Once
);
}
}
[TestFixture]
public class ValidatePaymentRequestMethod : PaymentServiceTests
{
[Test]
public void ValidatePaymentRequest_WithValidRequest_ShouldNotThrow()
{
// Arrange
var validRequest = new PaymentRequest
{
UserId = "user123",
Amount = 50.00m,
Currency = "USD",
PaymentMethod = "credit_card"
};
// Act & Assert
Assert.DoesNotThrow(() => _paymentService.ValidatePaymentRequest(validRequest));
}
[TestCase(null)]
[TestCase("")]
[TestCase(" ")]
public void ValidatePaymentRequest_WithInvalidUserId_ShouldThrowArgumentException(string invalidUserId)
{
// Arrange
var invalidRequest = new PaymentRequest
{
UserId = invalidUserId,
Amount = 50.00m,
Currency = "USD",
PaymentMethod = "credit_card"
};
// Act & Assert
var exception = Assert.Throws<ArgumentException>(
() => _paymentService.ValidatePaymentRequest(invalidRequest)
);
exception.Message.Should().Contain("UserId cannot be null or empty");
}
[TestCase("INVALID")]
[TestCase("123")]
[TestCase("")]
public void ValidatePaymentRequest_WithInvalidCurrency_ShouldThrowArgumentException(string invalidCurrency)
{
// Arrange
var invalidRequest = new PaymentRequest
{
UserId = "user123",
Amount = 50.00m,
Currency = invalidCurrency,
PaymentMethod = "credit_card"
};
// Act & Assert
var exception = Assert.Throws<ArgumentException>(
() => _paymentService.ValidatePaymentRequest(invalidRequest)
);
exception.Message.Should().Contain("Invalid currency code");
}
}
}
}
```
## Quality Validation
### Test Quality Checklist
- ✅ **AAA Pattern**: Arrange, Act, Assert structure
- ✅ **Descriptive Names**: Clear test method and describe block names
- ✅ **Single Responsibility**: Each test validates one specific behavior
- ✅ **Test Isolation**: Tests can run independently in any order
- ✅ **Proper Mocking**: Dependencies are properly mocked and verified
- ✅ **Edge Cases**: Boundary conditions and error scenarios covered
- ✅ **Accessibility**: Components tested for a11y compliance
- ✅ **Async Handling**: Promises and async operations properly tested
### Coverage Validation
- **Line Coverage**: Target 90%+ for generated tests
- **Branch Coverage**: All conditional paths tested
- **Function Coverage**: All exported functions tested
- **Statement Coverage**: All executable statements covered
This comprehensive unit test generator creates high-quality, maintainable tests that follow best practices and achieve excellent coverage across different testing frameworks.
==================== END: .hubtel-workflow/tasks/unit-test-generator.md ====================
==================== START: .hubtel-workflow/tasks/test-report-generator.md ====================
# Test Report Generator
## ⚠️ CRITICAL EXECUTION NOTICE ⚠️
**THIS IS AN EXECUTABLE WORKFLOW - NOT REFERENCE MATERIAL**
When this task is invoked:
1. **COMPREHENSIVE DATA COLLECTION** - Gather all testing metrics and results
2. **DETAILED ANALYSIS** - Process coverage, quality, and compliance data
3. **VISUAL REPORTING** - Generate charts, graphs, and visual representations
4. **ACTIONABLE INSIGHTS** - Provide specific recommendations with priorities
## Overview
This workflow generates comprehensive testing reports that combine coverage analysis, quality metrics, compliance assessment, and actionable recommendations. Reports are designed for both technical teams and stakeholders.
## Input Parameters
### Required Parameters
- **project_path**: Absolute path to the project root
- **report_type**: "summary" | "detailed" | "executive" | "technical"
- **output_format**: "markdown" | "html" | "pdf" | "json"
### Optional Parameters
- **include_trends**: boolean (default: true)
- **compare_baseline**: string (baseline report path for comparison)
- **focus_areas**: array ["coverage", "quality", "performance", "accessibility", "security"]
- **stakeholder_level**: "developer" | "lead" | "manager" | "executive"
## Report Generation Framework
### Phase 1: Data Collection and Analysis
```yaml
step: collect_testing_data
description: Gather comprehensive testing metrics from various sources
data_collection:
- coverage_metrics:
- line_coverage: Parse coverage reports (lcov, cobertura)
- branch_coverage: Extract branch coverage data
- function_coverage: Analyze function-level coverage
- file_coverage: Per-file coverage breakdown
- test_execution_data:
- test_results: Pass/fail rates, test counts
- performance_metrics: Test execution times
- flaky_tests: Tests with inconsistent results
- error_patterns: Common failure reasons
- quality_metrics:
- test_maintainability: Code complexity in tests
- assertion_quality: Meaningful vs trivial assertions
- test_isolation: Dependencies and side effects
- code_duplication: DRY violations in tests
```
### Phase 2: Compliance Assessment
```yaml
step: assess_hubtel_compliance
description: Evaluate project against Hubtel testing standards
compliance_evaluation:
- coverage_standards:
- minimum_coverage: 85% requirement assessment
- critical_path_coverage: Business logic coverage
- edge_case_coverage: Error and boundary testing
- regression_coverage: Bug prevention testing
- framework_compliance:
- required_frameworks: Vitest, Playwright, Karate, NUnit usage
- configuration_standards: Proper setup and configuration
- naming_conventions: Test file and function naming
- organization_patterns: Test structure and organization
- accessibility_compliance:
- wcag_aa_testing: Accessibility test coverage
- screen_reader_tests: Assistive technology compatibility
- keyboard_navigation: Navigation testing coverage
- color_contrast_tests: Visual accessibility validation
```
### Phase 3: Trend Analysis and Comparison
```yaml
step: analyze_trends_and_changes
description: Compare current metrics with historical data and baselines
trend_analysis:
- coverage_trends:
- coverage_over_time: Historical coverage progression
- coverage_by_feature: Feature-specific coverage trends
- regression_detection: Coverage decreases over time
- improvement_velocity: Rate of coverage improvement
- quality_trends:
- test_reliability: Flakiness trends over time
- performance_trends: Test execution speed changes
- maintainability_trends: Test complexity evolution
- defect_correlation: Test quality vs bug rates
- baseline_comparison:
- coverage_delta: Changes since baseline
- quality_improvements: Quality metric improvements
- new_gaps: Newly introduced coverage gaps
- resolved_issues: Fixed testing issues
```
### Phase 4: Report Generation
```yaml
step: generate_comprehensive_report
description: Create detailed testing report with visual elements and recommendations
report_generation:
- executive_summary:
- key_metrics_overview: High-level testing health
- compliance_status: Standards compliance summary
- critical_issues: Priority issues requiring attention
- success_highlights: Recent improvements and achievements
- detailed_analysis:
- coverage_breakdown: Detailed coverage analysis by component
- quality_assessment: Test quality metrics and trends
- performance_analysis: Test execution and reliability metrics
- compliance_review: Standard-by-standard compliance analysis
- visual_representations:
- coverage_charts: Coverage trends and breakdowns
- quality_graphs: Quality metrics visualization
- compliance_dashboards: Standards compliance overview
- trend_analysis: Historical data visualization
- actionable_recommendations:
- priority_matrix: Issues prioritized by impact and effort
- improvement_roadmap: Step-by-step improvement plan
- resource_requirements: Time and skill estimates
- success_metrics: KPIs for tracking improvement
```
## Report Templates
### Executive Summary Template
```markdown
# Testing Quality Report - Executive Summary
## 📊 Key Metrics Overview
- **Overall Test Coverage**: 78.5% ⬆️ (+5.2% from last month)
- **Quality Score**: 8.4/10 ⬆️ (+0.3 improvement)
- **Compliance Level**: 85% ✅ (Meeting Hubtel standards)
- **Critical Issues**: 3 🚨 (Down from 8 last month)
## 🎯 Compliance Status
| Standard | Status | Score | Trend |
|----------|--------|-------|-------|
| Minimum Coverage (85%) | ⚠️ | 78.5% | ⬆️ |
| Framework Compliance | ✅ | 95% | ➡️ |
| Accessibility Testing | 🚨 | 45% | ⬆️ |
| Performance Testing | ✅ | 90% | ⬆️ |
## 🚨 Critical Actions Required
1. **Increase Coverage** - 23 files below 60% coverage
2. **Accessibility Testing** - 67% of components missing a11y tests
3. **API Testing** - 5 critical endpoints without integration tests
## 🏆 Recent Achievements
- ✅ Migrated all tests to Vitest (100% complete)
- ✅ Implemented Playwright E2E testing framework
- ✅ Reduced test execution time by 35%
```
### Technical Report Template
```markdown
# Comprehensive Testing Analysis Report
## 📋 Project Overview
- **Project**: Hubtel Payment Platform
- **Analysis Date**: 2024-01-15
- **Total Files**: 1,247
- **Test Files**: 342
- **Frameworks**: Vitest, Playwright, Karate, NUnit
## 📈 Coverage Analysis
### Overall Coverage Metrics
```json
{
"line_coverage": 78.5,
"branch_coverage": 74.2,
"function_coverage": 82.1,
"statement_coverage": 79.3
}
```
### Coverage by Category
| Category | Coverage | Files | Status |
|----------|----------|-------|--------|
| Components | 85.2% | 89 | ✅ Good |
| Services | 72.1% | 45 | ⚠️ Needs Work |
| Utils | 91.4% | 23 | ✅ Excellent |
| API Routes | 58.7% | 34 | 🚨 Critical |
### Critical Coverage Gaps
1. **Payment Processing** (`src/services/payment/`)
- Current Coverage: 45.2%
- Critical Business Logic: ❌ Not Covered
- Recommendation: Priority 1 - Add comprehensive tests
2. **Authentication Service** (`src/auth/`)
- Current Coverage: 62.8%
- Security Impact: 🚨 High
- Recommendation: Priority 1 - Security testing required
## 🧪 Test Quality Analysis
### Quality Metrics
- **Test Reliability**: 94.2% (6 flaky tests identified)
- **Average Execution Time**: 45.3s (Target: <60s) ✅
- **Maintainability Score**: 8.4/10
- **Assertion Quality**: 87.3%
### Best Practices Compliance
- ✅ AAA Pattern: 94% of tests
- ✅ Descriptive Names: 89% of tests
- ⚠️ Single Responsibility: 76% of tests
- 🚨 Proper Cleanup: 62% of tests
## 🎯 Framework Analysis
### Frontend Testing (Next.js)
- **Unit Testing**: Vitest ✅ Properly configured
- **Component Testing**: @testing-library/react ✅
- **E2E Testing**: Playwright ✅ Setup complete
- **Coverage**: 82.4% ✅ Above target
### Backend Testing (.NET Core)
- **Unit Testing**: NUnit ✅ Well structured
- **API Testing**: Karate ✅ 67% endpoints covered
- **Integration**: TestContainers ⚠️ Limited usage
- **Coverage**: 71.8% ⚠️ Below target
## 📊 Accessibility Testing
### Current State
- **Components Tested**: 23/89 (25.8%)
- **WCAG AA Compliance**: 15/23 tested components
- **Screen Reader Tests**: 8 components
- **Keyboard Navigation**: 12 components
### Accessibility Gaps
1. **Form Components** - 12 forms missing a11y tests
2. **Modal Dialogs** - 5 modals without screen reader tests
3. **Navigation** - Main navigation missing keyboard tests
## 🚀 Performance Testing
### Test Performance Metrics
- **Average Test Suite Runtime**: 45.3s
- **Slowest Test File**: `payment.integration.test.ts` (8.2s)
- **Parallel Execution**: ✅ Enabled
- **CI Pipeline Time**: 3m 42s ✅ Under 5min target
### Performance Recommendations
1. **Optimize slow tests** - 8 tests taking >500ms
2. **Increase parallelization** - Current: 4 workers, Recommended: 6
3. **Mock optimization** - Replace real API calls in 12 tests
## 📋 Action Plan & Recommendations
### Immediate Actions (Next 2 Weeks)
1. **🚨 Priority 1**: Add tests for payment processing service
- Estimated Effort: 12 hours
- Impact: Critical business logic protection
- Assignee: Senior Developer
2. **🚨 Priority 1**: Security testing for authentication
- Estimated Effort: 8 hours
- Impact: Security vulnerability prevention
- Assignee: Security-focused Developer
3. **⚠️ Priority 2**: Implement accessibility testing framework
- Estimated Effort: 16 hours
- Impact: Compliance and user experience
- Assignee: Frontend Team
### Strategic Improvements (Next Month)
1. **Coverage Enhancement**
- Target: Reach 85% overall coverage
- Focus: API routes and service layers
- Timeline: 4 weeks
2. **Test Quality Improvement**
- Implement mutation testing
- Standardize testing patterns
- Timeline: 3 weeks
3. **CI/CD Integration**
- Enhanced coverage reporting
- Quality gates implementation
- Timeline: 2 weeks
## 📈 Success Metrics & KPIs
### Monthly Targets
- **Coverage**: Reach 85% (current: 78.5%)
- **Quality Score**: Maintain >8.5/10 (current: 8.4)
- **Flaky Tests**: <5 (current: 6)
- **CI Pipeline**: <5min (current: 3m 42s) ✅
### Quarterly Goals
- **Accessibility**: 90% component coverage
- **Performance**: All tests <100ms average
- **Compliance**: 100% Hubtel standards
- **Innovation**: Implement AI-assisted test generation
```
## Output Formats
### Markdown Report
```markdown
# [Generated comprehensive markdown report as shown above]
```
### HTML Dashboard
```html
<!DOCTYPE html>
<html>
<head>
<title>Testing Quality Dashboard</title>
<script src="https://cdn.plot.ly/plotly-latest.min.js"></script>
</head>
<body>
<!-- Interactive charts and metrics -->
<div id="coverage-chart"></div>
<div id="quality-trends"></div>
<div id="compliance-dashboard"></div>
</body>
</html>
```
### JSON Data Export
```json
{
"report_metadata": {
"generated_at": "2024-01-15T10:30:00Z",
"project": "hubtel-payment-platform",
"report_type": "comprehensive"
},
"summary_metrics": {
"coverage": 78.5,
"quality_score": 8.4,
"compliance_level": 85,
"critical_issues": 3
},
"detailed_analysis": {
"coverage_breakdown": {...},
"quality_metrics": {...},
"compliance_assessment": {...}
},
"recommendations": [...],
"action_items": [...]
}
```
This comprehensive reporting system provides detailed insights into testing quality, compliance status, and actionable recommendations for continuous improvement.
==================== END: .hubtel-workflow/tasks/test-report-generator.md ====================
==================== START: .hubtel-workflow/templates/vitest-unit-test-tmpl.ts ====================
// Vitest Unit Test Template
import { describe, it, expect, beforeEach, afterEach, vi } from 'vitest'
import { render, screen, fireEvent, waitFor } from '@testing-library/react'
import { Component } from '../Component'
// Mock dependencies
vi.mock('../hooks/useCustomHook')
vi.mock('../services/apiService')
const mockUseCustomHook = vi.mocked(useCustomHook)
const mockApiService = vi.mocked(apiService)
describe('Component', () => {
const defaultProps = {
// Define default props here
id: 'test-id',
onAction: vi.fn(),
initialValue: 'test'
}
beforeEach(() => {
vi.clearAllMocks()
// Set up common mock implementations
mockUseCustomHook.mockReturnValue({
data: null,
loading: false,
error: null
})
})
afterEach(() => {
vi.clearAllTimers()
})
describe('Rendering', () => {
it('should render with default props', () => {
render(<Component {...defaultProps} />)
expect(screen.getByTestId('test-id')).toBeInTheDocument()
})
it('should render loading state', () => {
mockUseCustomHook.mockReturnValue({
data: null,
loading: true,
error: null
})
render(<Component {...defaultProps} />)
expect(screen.getByRole('progressbar')).toBeInTheDocument()
expect(screen.getByText('Loading...')).toBeInTheDocument()
})
it('should render error state', () => {
const error = new Error('Test error')
mockUseCustomHook.mockReturnValue({
data: null,
loading: false,
error
})
render(<Component {...defaultProps} />)
expect(screen.getByText('Error: Test error')).toBeInTheDocument()
})
})
describe('User Interactions', () => {
it('should handle click events', async () => {
render(<Component {...defaultProps} />)
const button = screen.getByRole('button', { name: /action/i })
fireEvent.click(button)
expect(defaultProps.onAction).toHaveBeenCalledTimes(1)
})
it('should handle keyboard events', () => {
render(<Component {...defaultProps} />)
const input = screen.getByRole('textbox')
fireEvent.keyDown(input, { key: 'Enter', code: 'Enter' })
expect(defaultProps.onAction).toHaveBeenCalled()
})
})
describe('Data Fetching', () => {
it('should fetch data on mount', async () => {
mockApiService.fetchData.mockResolvedValue({ result: 'success' })
render(<Component {...defaultProps} />)
await waitFor(() => {
expect(mockApiService.fetchData).toHaveBeenCalledWith(defaultProps.id)
})
})
it('should handle fetch errors', async () => {
mockApiService.fetchData.mockRejectedValue(new Error('Network error'))
render(<Component {...defaultProps} />)
await waitFor(() => {
expect(screen.getByText('Unable to load data')).toBeInTheDocument()
})
})
})
describe('Accessibility', () => {
it('should have proper ARIA attributes', () => {
render(<Component {...defaultProps} />)
expect(screen.getByRole('main')).toHaveAttribute('aria-label')
expect(screen.getByRole('button')).toHaveAttribute('aria-describedby')
})
it('should support keyboard navigation', () => {
render(<Component {...defaultProps} />)
const firstFocusable = screen.getByRole('button')
firstFocusable.focus()
expect(firstFocusable).toHaveFocus()
})
it('should announce important state changes', async () => {
render(<Component {...defaultProps} />)
const button = screen.getByRole('button')
fireEvent.click(button)
await waitFor(() => {
expect(screen.getByRole('status')).toHaveTextContent('Action completed')
})
})
})
describe('Edge Cases', () => {
it('should handle null props gracefully', () => {
expect(() => {
render(<Component {...defaultProps} initialValue={null} />)
}).not.toThrow()
})
it('should handle empty state', () => {
mockUseCustomHook.mockReturnValue({
data: [],
loading: false,
error: null
})
render(<Component {...defaultProps} />)
expect(screen.getByText('No items found')).toBeInTheDocument()
})
})
})
==================== END: .hubtel-workflow/templates/vitest-unit-test-tmpl.ts ====================
==================== START: .hubtel-workflow/templates/playwright-e2e-test-tmpl.ts ====================
// Playwright E2E Test Template
import { test, expect } from '@playwright/test'
test.describe('User Journey - Feature Name', () => {
test.beforeEach(async ({ page }) => {
// Navigate to starting page
await page.goto('/dashboard')
// Wait for page to be ready
await page.waitForLoadState('networkidle')
})
test.describe('Happy Path Scenarios', () => {
test('should complete main user workflow', async ({ page }) => {
// Step 1: Initial state verification
await expect(page.locator('[data-testid="welcome-message"]')).toBeVisible()
await expect(page).toHaveTitle(/Dashboard/)
// Step 2: Navigate to feature
await page.click('[data-testid="feature-nav-link"]')
await page.waitForURL('**/feature')
// Step 3: Interact with main feature
await page.fill('[data-testid="input-field"]', 'test data')
await page.click('[data-testid="submit-button"]')
// Step 4: Verify success state
await expect(page.locator('[data-testid="success-message"]')).toBeVisible()
await expect(page.locator('[data-testid="result-display"]')).toContainText('Success')
})
test('should handle form submission with valid data', async ({ page }) => {
await page.goto('/form')
// Fill form with valid data
await page.fill('[name="email"]', 'test@example.com')
await page.fill('[name="password"]', 'SecurePass123!')
await page.check('[name="agree-terms"]')
// Submit form
await page.click('[type="submit"]')
// Verify successful submission
await expect(page.locator('.success-notification')).toBeVisible()
await expect(page).toHaveURL('**/success')
})
})
test.describe('Error Scenarios', () => {
test('should handle network errors gracefully', async ({ page }) => {
// Simulate network failure
await page.route('**/api/data', (route) => {
route.abort('internetdisconnected')
})
await page.goto('/dashboard')
await page.click('[data-testid="load-data-button"]')
// Verify error handling
await expect(page.locator('[data-testid="error-message"]')).toBeVisible()
await expect(page.locator('[data-testid="retry-button"]')).toBeVisible()
})
test('should validate required form fields', async ({ page }) => {
await page.goto('/form')
// Try to submit without filling required fields
await page.click('[type="submit"]')
// Verify validation errors
await expect(page.locator('[data-testid="email-error"]')).toBeVisible()
await expect(page.locator('[data-testid="password-error"]')).toBeVisible()
// Form should not submit
await expect(page).toHaveURL('**/form')
})
})
test.describe('Accessibility Testing', () => {
test('should be keyboard navigable', async ({ page }) => {
await page.goto('/dashboard')
// Tab through interactive elements
await page.keyboard.press('Tab')
await expect(page.locator('[data-testid="first-button"]')).toBeFocused()
await page.keyboard.press('Tab')
await expect(page.locator('[data-testid="second-button"]')).toBeFocused()
// Test Enter key activation
await page.keyboard.press('Enter')
await expect(page.locator('[data-testid="modal"]')).toBeVisible()
})
test('should have proper ARIA labels and roles', async ({ page }) => {
await page.goto('/dashboard')
// Check main landmark
await expect(page.locator('main')).toHaveAttribute('role', 'main')
// Check button accessibility
const actionButton = page.locator('[data-testid="action-button"]')
await expect(actionButton).toHaveAttribute('aria-label')
await expect(actionButton).toHaveAttribute('role', 'button')
// Check form accessibility
await expect(page.locator('[name="email"]')).toHaveAttribute('aria-required', 'true')
})
test('should announce important state changes', async ({ page }) => {
await page.goto('/form')
// Submit form to trigger state change
await page.fill('[name="email"]', 'test@example.com')
await page.click('[type="submit"]')
// Verify live region announcement
await expect(page.locator('[aria-live="polite"]')).toContainText('Form submitted successfully')
})
})
test.describe('Mobile Responsiveness', () => {
test('should work on mobile devices', async ({ page }) => {
// Set mobile viewport
await page.setViewportSize({ width: 375, height: 667 })
await page.goto('/dashboard')
// Verify mobile-specific elements
await expect(page.locator('[data-testid="mobile-menu-button"]')).toBeVisible()
// Test mobile navigation
await page.click('[data-testid="mobile-menu-button"]')
await expect(page.locator('[data-testid="mobile-nav-menu"]')).toBeVisible()
// Test touch interactions
await page.tap('[data-testid="feature-card"]')
await expect(page).toHaveURL('**/feature')
})
test('should handle touch gestures', async ({ page }) => {
await page.setViewportSize({ width: 375, height: 667 })
await page.goto('/gallery')
// Test swipe gesture (if implemented)
const gallery = page.locator('[data-testid="image-gallery"]')
await gallery.hover()
await page.mouse.down()
await page.mouse.move(100, 0)
await page.mouse.up()
// Verify swipe action
await expect(page.locator('[data-testid="next-image"]')).toBeVisible()
})
})
test.describe('Performance Testing', () => {
test('should load page within acceptable time', async ({ page }) => {
const startTime = Date.now()
await page.goto('/dashboard')
await page.waitForLoadState('networkidle')
const loadTime = Date.now() - startTime
expect(loadTime).toBeLessThan(3000) // 3 seconds max
})
test('should handle large datasets efficiently', async ({ page }) => {
await page.goto('/data-table')
// Load large dataset
await page.click('[data-testid="load-1000-items"]')
// Verify virtual scrolling or pagination works
await expect(page.locator('[data-testid="table-row"]').first()).toBeVisible()
// Test scrolling performance
await page.locator('[data-testid="table-container"]').scroll({ top: 1000 })
await expect(page.locator('[data-testid="table-row"]')).toHaveCountGreaterThan(10)
})
})
test.describe('Integration Testing', () => {
test('should integrate with external services', async ({ page }) => {
// Mock external API
await page.route('**/api/external-service', async (route) => {
await route.fulfill({
status: 200,
contentType: 'application/json',
body: JSON.stringify({ success: true, data: 'mocked data' })
})
})
await page.goto('/integration-test')
await page.click('[data-testid="call-external-api"]')
await expect(page.locator('[data-testid="api-response"]')).toContainText('mocked data')
})
test('should handle authentication flow', async ({ page }) => {
// Start from login page
await page.goto('/login')
// Login with valid credentials
await page.fill('[name="username"]', 'testuser')
await page.fill('[name="password"]', 'password123')
await page.click('[type="submit"]')
// Verify redirect to dashboard
await expect(page).toHaveURL('**/dashboard')
// Verify authenticated state
await expect(page.locator('[data-testid="user-menu"]')).toBeVisible()
// Test logout
await page.click('[data-testid="logout-button"]')
await expect(page).toHaveURL('**/login')
})
})
})
==================== END: .hubtel-workflow/templates/playwright-e2e-test-tmpl.ts ====================
==================== START: .hubtel-workflow/templates/karate-api-test-tmpl.feature ====================
# Karate API Test Template
Feature: API Testing for [API Name]
Background:
* url apiBaseUrl
* def authToken = karate.properties['auth.token']
* header Authorization = 'Bearer ' + authToken
* header Content-Type = 'application/json'
Scenario: Get resource by ID - Happy Path
Given path 'api/resource/123'
When method GET
Then status 200
And match response ==
"""
{
id: 123,
name: '#string',
status: 'active',
createdAt: '#string',
updatedAt: '#string'
}
"""
And match response.id == 123
And match response.name == '#present'
Scenario: Create new resource - Valid data
Given path 'api/resource'
And request
"""
{
name: 'Test Resource',
description: 'Test description',
category: 'test'
}
"""
When method POST
Then status 201
And match response.id == '#number'
And match response.name == 'Test Resource'
And match response.status == 'pending'
Scenario: Update existing resource - Partial update
Given path 'api/resource/123'
And request { name: 'Updated Name' }
When method PATCH
Then status 200
And match response.name == 'Updated Name'
And match response.id == 123
Scenario: Delete resource - Valid ID
Given path 'api/resource/123'
When method DELETE
Then status 204
Scenario Outline: Create resource with invalid data - Validation errors
Given path 'api/resource'
And request <requestData>
When method POST
Then status 400
And match response.error == '#string'
And match response.message contains <expectedError>
Examples:
| requestData | expectedError |
| {} | 'name is required' |
| { name: '' } | 'name cannot be empty' |
| { name: 'a', description: null } | 'invalid description' |
Scenario: Get resource with invalid ID - Not Found
Given path 'api/resource/99999'
When method GET
Then status 404
And match response ==
"""
{
error: 'Resource not found',
code: 'RESOURCE_NOT_FOUND',
statusCode: 404
}
"""
Scenario: Unauthorized access - Missing token
Given path 'api/resource/123'
And header Authorization = ''
When method GET
Then status 401
And match response.error == 'Unauthorized'
Scenario: Forbidden access - Insufficient permissions
Given path 'api/admin/resource'
And def userToken = karate.properties['user.token']
And header Authorization = 'Bearer ' + userToken
When method GET
Then status 403
And match response.error == 'Forbidden'
Scenario: API Rate Limiting - Too many requests
Given path 'api/resource/123'
And def results = []
# Make multiple rapid requests
And def fun = function(x){ karate.http('GET', apiBaseUrl + '/api/resource/123', null, { Authorization: 'Bearer ' + authToken }) }
And def responses = karate.repeat(100, fun)
# At least one should be rate limited
And def rateLimited = responses.filter(function(r){ return r.status == 429 })
And assert rateLimited.length > 0
Scenario: Pagination - Get paginated results
Given path 'api/resources'
And param page = 1
And param limit = 10
When method GET
Then status 200
And match response ==
"""
{
data: '#[10] object',
pagination: {
page: 1,
limit: 10,
total: '#number',
hasNext: '#boolean',
hasPrev: false
}
}
"""
And assert response.data.length <= 10
Scenario: Search functionality - Filter by criteria
Given path 'api/resources'
And param search = 'test'
And param category = 'active'
When method GET
Then status 200
And match each response.data contains { category: 'active' }
And def names = response.data[*].name
And match names contains only '#string'
Scenario: Bulk operations - Create multiple resources
Given path 'api/resources/bulk'
And request
"""
{
resources: [
{ name: 'Resource 1', category: 'test' },
{ name: 'Resource 2', category: 'test' },
{ name: 'Resource 3', category: 'test' }
]
}
"""
When method POST
Then status 201
And match response.created == 3
And match response.resources == '#[3] object'
And match each response.resources contains { id: '#number' }
Scenario: File upload - Valid file
Given path 'api/resource/123/upload'
And multipart file file = { read: 'test-file.pdf', filename: 'document.pdf', contentType: 'application/pdf' }
When method POST
Then status 200
And match response.filename == 'document.pdf'
And match response.size == '#number'
And match response.url == '#string'
Scenario: Async operation - Long running task
Given path 'api/resource/123/process'
And request { operation: 'complex_calculation' }
When method POST
Then status 202
And match response.taskId == '#string'
And def taskId = response.taskId
# Poll for completion
* def sleep = function(ms){ java.lang.Thread.sleep(ms) }
Given path 'api/tasks/' + taskId
And retry until responseStatus == 200 && response.status == 'completed'
When method GET
And call sleep 1000
Then match response.status == 'completed'
And match response.result == '#present'
Scenario: API versioning - Different versions
Given path 'v1/api/resource/123'
When method GET
Then status 200
And match response.version == 'v1'
Given path 'v2/api/resource/123'
When method GET
Then status 200
And match response.version == 'v2'
And match response.metadata == '#present'
Scenario: Error handling - Server errors
Given path 'api/resource/trigger-error'
When method POST
Then status 500
And match response ==
"""
{
error: 'Internal server error',
code: 'INTERNAL_ERROR',
statusCode: 500,
timestamp: '#string',
requestId: '#string'
}
"""
Scenario: Data integrity - Concurrent updates
Given path 'api/resource/123'
When method GET
Then status 200
And def version = response.version
# Simulate concurrent update
Given path 'api/resource/123'
And request { name: 'Updated Name', version: version }
When method PUT
Then status 200
# Second update with stale version should fail
Given path 'api/resource/123'
And request { name: 'Another Update', version: version }
When method PUT
Then status 409
And match response.error == 'Conflict'
Scenario: Performance testing - Response time validation
Given path 'api/resource/123'
When method GET
Then status 200
* def responseTime = karate.get('responseTime')
And assert responseTime < 1000
==================== END: .hubtel-workflow/templates/karate-api-test-tmpl.feature ====================
==================== START: .hubtel-workflow/data/hubtel-kb.md ====================
# Hubtel Development Knowledge Base
## Overview
The Hubtel CQT Expansion Pack provides AI agents specialized for Hubtel's development workflow, including Azure DevOps integration, frontend/backend coordination, and automated task management.
## Hubtel Technology Stack
### Frontend Technologies
- **Next.js**: React-based framework for production-ready applications
- **Nuxt.js**: Vue.js framework for server-side rendered applications
- **Testing**: Vitest for unit testing, Playwright for end-to-end testing
- **Styling**: Tailwind CSS, CSS Modules, or styled-components depending on project
### Backend Technologies
- **.NET Core**: Primary backend framework for APIs and services
- **Entity Framework Core**: ORM for database operations
- **PostgreSQL**: Primary relational database
- **MongoDB**: Document database for specific use cases
- **Testing**: Karate for API testing, mutation testing for code quality
### Development Tools
- **Azure DevOps**: Project management, CI/CD, and code repositories
- **Docker**: Containerization for local development and deployment
- **OpenTelemetry**: Observability and logging framework
- **Git**: Version control with Azure Repos integration
## Development Workflow
### Task Management
- **Task Sizing**: All tasks should be completable within 1 hour
- **Acceptance Criteria**: Every task must have clear, testable acceptance criteria
- **Testing Requirements**: Unit tests and E2E tests are mandatory for all features
- **Code Review**: All code must be reviewed before merging
### Entry Points
1. **Azure DevOps Import**: Import existing tasks for enhancement and implementation
2. **Task Description**: Process free-form task descriptions into structured work
3. **Planning Phase**: Full requirement gathering and architecture planning
4. **Idea to Tasks**: Convert business ideas into implementable Azure work items
### Coordination Patterns
- **API Changes**: Coordinate between frontend and backend when APIs change
- **Docker Updates**: Share new compose files for local development
- **Documentation**: Maintain API documentation via Swagger/OpenAPI
- **Communication**: Use Teams for real-time coordination
## Quality Standards
### Code Standards
- Follow Hubtel coding guidelines: https://dev-docs.hubtel.com/introduction.html
- Use consistent naming conventions across frontend and backend
- Implement proper error handling and logging
- Include comprehensive unit and integration tests
### Testing Requirements
- **Frontend**: Vitest for unit tests, Playwright for E2E
- **Backend**: Karate for API tests, mutation testing for quality
- **Coverage**: Minimum 80% code coverage for new features
- **E2E**: Critical user journeys must have automated E2E tests
### Documentation Standards
- API documentation via OpenAPI/Swagger
- Code documentation for complex business logic
- README files for setup and development instructions
- Architecture decisions documented in ADRs
## Integration Patterns
### Azure DevOps Integration
- Work items linked to commits via task IDs
- Automatic status updates based on code commits
- Parent-child relationships for epic/feature/story hierarchy
- Time tracking for development effort estimation
### Cross-Team Coordination
- Shared Docker Compose files for consistent environments
- API contract-first development approach
- Regular API specification updates via Postman/Swagger
- Teams notifications for breaking changes
### Environment Management
- Local development via Docker Compose
- Environment-specific configuration management
- Secrets management via Azure Key Vault
- Consistent deployment pipelines across environments
## Best Practices
### Development Practices
- Branch naming: feature/AZ-{task-id}-{description}
- Commit messages: {type}(AZ-{task-id}): {description}
- Pull request templates with checklists
- Automated testing in CI/CD pipeline
### Performance Considerations
- Database query optimization with EF Core
- Frontend bundle optimization and code splitting
- API response caching strategies
- Monitoring and alerting via OpenTelemetry
### Security Practices
- Input validation on all API endpoints
- Authentication and authorization patterns
- Secure secret management
- Regular security scanning and updates
## Common Scenarios
### Frontend Task Implementation
1. Parse HTML artifacts from UX team
2. Implement responsive component with Next.js/Nuxt.js
3. Add Vitest unit tests for component logic
4. Create Playwright E2E tests for user interactions
5. Update API integration based on backend specifications
### Backend Task Implementation
1. Design API endpoints following REST principles
2. Implement .NET Core controllers and services
3. Add Entity Framework Core data models and migrations
4. Create Karate tests for API endpoints
5. Add OpenTelemetry logging and monitoring
### Integration Task Implementation
1. Coordinate API changes between frontend and backend
2. Update Docker Compose files for new services
3. Generate updated OpenAPI specifications
4. Notify teams of breaking changes
5. Validate end-to-end functionality
This knowledge base serves as the foundation for all Hubtel-specific agents, ensuring consistent development practices and quality standards across all projects.
==================== END: .hubtel-workflow/data/hubtel-kb.md ====================