beyhan/ClassicAssist.Avalonia
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b7db07060fcbf017429f64877e5b54975ec3e26a
ClassicAssist.Avalonia/.qoder/repowiki/en/content/Testing and Debugging.md
T
Beyhan Oğur d5f52cc3d3 first commit
2026-09-03 04:45:36 +03:00

15 KiB
Raw Blame History

Testing and Debugging

**Referenced Files in This Document** - [ClassicAssist.Tests.csproj](file://ClassicAssist.Tests/ClassicAssist.Tests.csproj) - [ReplayPacketLog.cs](file://ClassicAssist.Tests/ReplayPacketLog.cs) - [IncomingPacketHandlerTests.cs](file://ClassicAssist.Tests/IncomingPacketHandlerTests.cs) - [OutgoingPacketHandlerTests.cs](file://ClassicAssist.Tests/OutgoingPacketHandlerTests.cs) - [packetlengths.json](file://ClassicAssist.Tests/packetlengths.json) - [Engine.cs](file://ClassicAssist.Shared/Engine.cs) - [IncomingPacketHandlers.cs](file://ClassicAssist.Shared/UO/Network/IncomingPacketHandlers.cs) - [OutgoingPacketHandlers.cs](file://ClassicAssist.Shared/UO/Network/OutgoingPacketHandlers.cs) - [PacketFilter.cs](file://ClassicAssist.Shared/UO/Network/PacketFilter/PacketFilter.cs) - [App.axaml.cs](file://ClassicAssist.Avalonia/App.axaml.cs) - [Program.cs](file://ClassicAssist.Avalonia/Program.cs) - [azure-pipelines.yml](file://azure-pipelines.yml) - [appveyor.yml](file://appveyor.yml)

Table of Contents

  1. Introduction
  2. Project Structure
  3. Core Components
  4. Architecture Overview
  5. Detailed Component Analysis
  6. Dependency Analysis
  7. Performance Considerations
  8. Troubleshooting Guide
  9. Conclusion
  10. Appendices

Introduction

This document provides comprehensive testing and debugging guidance for ClassicAssist.Avalonia. It covers unit test setup, mocking strategies, assertion libraries, integration testing approaches (including end-to-end scenarios, network simulation, and performance testing), debugging techniques (logging configuration, memory profiling, and network analysis), the replay packet log system for reproducing network issues and validating packet handlers, continuous integration pipelines with automated testing and code coverage, and cross-platform debugging workflows.

Project Structure

The repository includes a dedicated test project and CI configurations:

  • Unit tests are organized under ClassicAssist.Tests with feature-based folders (Agents, Filters, MacroCommands).
  • Integration/UI tests exist under ClassicAssist.UITest and UITest.
  • CI is configured via Azure Pipelines and AppVeyor.
graph TB
subgraph "Unit Tests"
T1["ClassicAssist.Tests"]
T1A["Agents/*"]
T1B["Filters/*"]
T1C["MacroCommands/*"]
T1D["IncomingPacketHandlerTests.cs"]
T1E["OutgoingPacketHandlerTests.cs"]
T1F["ReplayPacketLog.cs"]
T1G["packetlengths.json"]
end
subgraph "UI Tests"
U1["ClassicAssist.UITest"]
U2["UITest"]
end
subgraph "CI"
C1["azure-pipelines.yml"]
C2["appveyor.yml"]
end
T1 --> T1A
T1 --> T1B
T1 --> T1C
T1 --> T1D
T1 --> T1E
T1 --> T1F
T1 --> T1G
U1 --> T1
U2 --> T1
C1 --> T1
C2 --> T1

[No sources needed since this diagram shows conceptual structure]

Core Components

Key components relevant to testing and debugging:

  • Test project configuration and dependencies
  • Packet handler tests for incoming/outgoing packets
  • Replay packet log utility for deterministic network reproduction
  • Shared engine and packet handling infrastructure used by tests

Section sources

Architecture Overview

Testing and debugging interact with the shared networking layer and UI entry points. The following diagram maps how tests exercise packet handlers and how the application initializes for debugging.

graph TB
subgraph "Test Layer"
TH["IncomingPacketHandlerTests.cs"]
OH["OutgoingPacketHandlerTests.cs"]
RL["ReplayPacketLog.cs"]
end
subgraph "Shared Networking"
IPH["IncomingPacketHandlers.cs"]
OPH["OutgoingPacketHandlers.cs"]
PF["PacketFilter.cs"]
ENG["Engine.cs"]
end
subgraph "Avalonia App"
APP["App.axaml.cs"]
PROG["Program.cs"]
end
TH --> IPH
OH --> OPH
RL --> IPH
RL --> OPH
TH --> ENG
OH --> ENG
PF --> IPH
PF --> OPH
APP --> PROG

Diagram sources

Detailed Component Analysis

Unit Testing Framework Setup

  • Test project file defines dependencies and framework references. Review it to understand which testing frameworks and assertion libraries are in use.
  • Organize tests by feature (Agents, Filters, MacroCommands) to improve maintainability and discoverability.
  • Use data-driven tests where appropriate (e.g., JSON fixtures like packetlengths.json) to validate packet parsing and length checks.

Practical tips:

  • Keep test classes focused on single responsibilities.
  • Prefer deterministic inputs and outputs; avoid flaky timing-dependent assertions.
  • Centralize common setup logic in base classes or helper methods within the test project.

Section sources

Mocking Strategies

  • For packet handlers and engine interactions, isolate behavior using mocks or stubs to simulate server responses without real network calls.
  • Replace I/O-bound operations (network, file system) with in-memory implementations during tests.
  • Ensure mocks verify call counts and parameters to assert correct handler wiring.

Guidance:

  • Create small interfaces around external dependencies when possible to enable substitution.
  • Validate that mocked behaviors reflect realistic edge cases (malformed packets, unexpected sequences).

[No sources needed since this section provides general guidance]

Assertion Libraries

  • Confirm the assertion library referenced in the test project file and align all tests to its idioms.
  • Use descriptive messages in assertions to aid debugging failures.
  • Group related assertions logically per test case.

Section sources

Integration Testing Approaches

  • End-to-end scenarios can be exercised through UI tests (ClassicAssist.UITest, UITest) to validate user flows across Avalonia views and view models.
  • Network simulation should rely on replay logs to reproduce exact packet sequences deterministically.
  • Performance tests should measure critical paths (packet processing, UI rendering) using consistent workloads and environment settings.

Recommendations:

  • Separate smoke tests from full regression suites.
  • Use headless execution for CI-friendly UI tests where supported.
  • Capture metrics and artifacts (logs, traces) for each run.

[No sources needed since this section provides general guidance]

Network Simulation and Replay Packet Log System

The replay packet log system enables deterministic reproduction of network sessions for testing packet handlers and diagnosing issues.

sequenceDiagram
participant Test as "ReplayPacketLog.cs"
participant InPkt as "IncomingPacketHandlers.cs"
participant OutPkt as "OutgoingPacketHandlers.cs"
participant Filter as "PacketFilter.cs"
participant Engine as "Engine.cs"
Test->>InPkt : "Inject recorded incoming packets"
InPkt->>Filter : "Apply filters"
Filter-->>InPkt : "Filtered stream"
InPkt->>Engine : "Dispatch to handlers"
Test->>OutPkt : "Trigger outgoing actions"
OutPkt->>Filter : "Apply filters"
Filter-->>OutPkt : "Filtered stream"
OutPkt->>Engine : "Dispatch to handlers"
Test-->>Test : "Assert state changes and outcomes"

Diagram sources

Implementation notes:

  • Use the replay log to feed known packet sequences into the incoming handler pipeline.
  • Assert expected side effects (state transitions, UI updates) after each batch.
  • Combine with packet length validation fixtures to ensure robustness against malformed input.

Section sources

Incoming and Outgoing Packet Handler Tests

  • IncomingPacketHandlerTests validates server-to-client packet processing paths.
  • OutgoingPacketHandlerTests validates client-to-server packet dispatch and filtering.

Best practices:

  • Cover normal flows and error conditions (invalid payloads, unexpected states).
  • Verify filter behavior and handler registration order.
  • Use deterministic fixtures and clear assertions.

Section sources

Application Entry Points for Debugging

  • Program.cs initializes the runtime and platform-specific setup.
  • App.axaml.cs configures the Avalonia application lifecycle and resources.

Debugging workflow:

  • Attach a debugger to the running process at startup.
  • Set breakpoints in App initialization and key handler entry points.
  • Inspect configuration and resource loading to rule out environment-related issues.

Section sources

Dependency Analysis

The test suite depends on shared networking and engine components. Understanding these relationships helps target tests effectively and avoid unnecessary coupling.

graph LR
T_In["IncomingPacketHandlerTests.cs"] --> H_In["IncomingPacketHandlers.cs"]
T_Out["OutgoingPacketHandlerTests.cs"] --> H_Out["OutgoingPacketHandlers.cs"]
T_Replay["ReplayPacketLog.cs"] --> H_In
T_Replay --> H_Out
H_In --> F["PacketFilter.cs"]
H_Out --> F
H_In --> E["Engine.cs"]
H_Out --> E

Diagram sources

Section sources

Performance Considerations

  • Profile packet processing hot paths using CPU profilers to identify bottlenecks in parsing and handler dispatch.
  • Measure memory allocations during large packet batches; consider object pooling for frequently allocated structures.
  • Use replay logs to create stable benchmarks for regression detection.
  • Monitor UI thread responsiveness during heavy network activity; offload non-UI work to background threads.

[No sources needed since this section provides general guidance]

Troubleshooting Guide

Common debugging techniques:

  • Logging configuration: Enable detailed logs around packet handlers and filters to trace message flow and errors.
  • Memory profiling: Capture snapshots during long sessions to detect leaks and high allocation rates.
  • Network analysis: Use replay logs to reproduce issues locally; compare expected vs actual state transitions.
  • Cross-platform issues: Run tests on multiple platforms; isolate platform-specific code paths in App and Program initialization.

Platform-specific troubleshooting:

  • Verify platform detection and dispatcher invoker usage in the Avalonia app.
  • Check resource loading differences between Windows and Linux/macOS.
  • Validate keyboard/mouse input behaviors and window management quirks.

Section sources

Conclusion

By leveraging the test project structure, packet handler tests, and the replay packet log system, you can build robust unit and integration tests for ClassicAssist.Avalonia. Combine deterministic network simulation with targeted logging and profiling to diagnose issues efficiently. CI pipelines automate testing and coverage, ensuring quality across platforms.

[No sources needed since this section summarizes without analyzing specific files]

Appendices

Continuous Integration Setup

  • Azure Pipelines and AppVeyor define automated builds and tests.
  • Configure steps to restore dependencies, build projects, run unit tests, and collect coverage reports.
  • Publish test results and artifacts for post-run analysis.

Section sources

Reference in New Issue View Git Blame Copy Permalink