icub3d/decentcom
1
0
Fork 0
Code Issues 21 Pull requests Projects Releases Packages 1 Wiki Activity Actions

Feature: Integration Testing Suite #67

New issue
Open
opened 2026-04-26 16:46:22 +00:00 by icub3d · 0 comments
icub3d commented 2026-04-26 16:46:22 +00:00
Owner
Copy link

Migrated from GitHub issue icub3d/decentcom#94
Original Author: @icub3d
Original Date: 2026-04-18T20:32:54Z

Feature: Integration Testing Suite

Overview

Implement a comprehensive integration testing suite that runs against actual server instances (open, private, strict). These tests will simulate a full client lifecycle: authentication, performing core actions (REST), and receiving real-time updates (Gateway/WebSocket). This ensures system-level correctness and protocol compliance across all server configurations.

Background

Currently, we have unit tests and a test-setup tool to bootstrap development databases. However, we lack a way to automatically verify that a client can successfully interact with a running server for end-to-end flows. This feature will leverage the Rust SDK (#85) to provide a stable, maintainable way to test our protocol implementations.

Requirements

  • New workspace member tests/integration/ or integration-tests/.
  • Integration with the Rust SDK (#85) for all client-side operations.
  • Automated lifecycle management for test servers:
    • Spin up server instances with specific test-configs/*.toml.
    • Isolate test databases (SQLite) and media storage for each test run to avoid cross-test contamination.
    • Clean up resources after tests complete.
  • Authentication testing:
    • Verify the two-step challenge-response flow works as expected.
    • Test edge cases (invalid signatures, expired challenges).
  • Core action testing (REST):
    • Create/Read/Update/Delete (CRUD) for: Channels, Messages, Roles, Members, Invites, Threads, Reactions, and Attachments.
    • Verify permission checks (e.g., a member without SEND_MESSAGES is blocked).
  • Real-time gateway testing (WebSocket):
    • Verify that actions performed via REST trigger the correct Gateway events (e.g., MESSAGE_CREATE when a message is sent).
    • Test heartbeating and connection resilience.
  • Multi-configuration support:
    • Run the same test suite against open, private, and strict server modes to ensure behavior consistency or expected differences.

Design

Component Changes

  • A new crate integration-tests/ in the root workspace.
  • Dependency on decentcom-sdk (from #85).
  • Dependency on sqlx (for direct DB verification when needed).

Implementation Strategy

  1. Server Orchestrator: A utility to start/stop the server binary with custom environment variables (e.g., DATABASE_URL, SERVER_CONFIG_PATH).
  2. Test Runner: Leverage tokio::test and the SDK's Client.
  3. Verification:
    • Perform an action via SDK.
    • Verify the API response.
    • (Optional) Verify the side-effect directly in the database using sqlx.
    • (Optional) Verify the corresponding event was received on a Gateway stream.

Task List

  • Scaffold integration-tests/ crate and workspace configuration.
  • Implement a TestServer helper that manages the server process and temporary SQLite database.
  • Implement base test setup: Identity generation and SDK Client initialization.
  • Phase 1: Authentication tests.
  • Phase 2: Channel and Message CRUD tests.
  • Phase 3: Permissions and Roles tests (verifying open/private/strict behaviors).
  • Phase 4: Gateway event verification.
  • Phase 5: Attachment and Media tests.
  • Integrate with CI (GitHub Actions) to run integration tests on PRs.

Test List

  • test_auth_flow: Complete challenge-response and session token acquisition.
  • test_message_send_receive: Send a message via REST, verify it appears in history and arrives via Gateway.
  • test_permission_enforcement: Attempt unauthorized actions and verify 403 responses.
  • test_multi_server_config: Run a standard test suite against all three default configs.

Open Questions

  • Should we use a tool like testcontainers or stick to spawning local processes for simplicity? (Recommendation: Start with local processes for faster feedback).
  • How to handle WebRTC/Media testing in integration? (Recommendation: Out of scope for phase 1; focus on REST/Gateway first).
  • Should this be a separate crate or live in server/tests/? (Recommendation: Separate crate to ensure it only uses the public API/SDK).
**Migrated from GitHub issue icub3d/decentcom#94** **Original Author:** @icub3d **Original Date:** 2026-04-18T20:32:54Z --- # Feature: Integration Testing Suite ## Overview Implement a comprehensive integration testing suite that runs against actual server instances (open, private, strict). These tests will simulate a full client lifecycle: authentication, performing core actions (REST), and receiving real-time updates (Gateway/WebSocket). This ensures system-level correctness and protocol compliance across all server configurations. ## Background Currently, we have unit tests and a `test-setup` tool to bootstrap development databases. However, we lack a way to automatically verify that a client can successfully interact with a running server for end-to-end flows. This feature will leverage the Rust SDK (#85) to provide a stable, maintainable way to test our protocol implementations. ## Requirements - [ ] New workspace member `tests/integration/` or `integration-tests/`. - [ ] Integration with the Rust SDK (#85) for all client-side operations. - [ ] Automated lifecycle management for test servers: - Spin up `server` instances with specific `test-configs/*.toml`. - Isolate test databases (SQLite) and media storage for each test run to avoid cross-test contamination. - Clean up resources after tests complete. - [ ] Authentication testing: - Verify the two-step challenge-response flow works as expected. - Test edge cases (invalid signatures, expired challenges). - [ ] Core action testing (REST): - Create/Read/Update/Delete (CRUD) for: Channels, Messages, Roles, Members, Invites, Threads, Reactions, and Attachments. - Verify permission checks (e.g., a member without `SEND_MESSAGES` is blocked). - [ ] Real-time gateway testing (WebSocket): - Verify that actions performed via REST trigger the correct Gateway events (e.g., `MESSAGE_CREATE` when a message is sent). - Test heartbeating and connection resilience. - [ ] Multi-configuration support: - Run the same test suite against `open`, `private`, and `strict` server modes to ensure behavior consistency or expected differences. ## Design ### Component Changes - A new crate `integration-tests/` in the root workspace. - Dependency on `decentcom-sdk` (from #85). - Dependency on `sqlx` (for direct DB verification when needed). ### Implementation Strategy 1. **Server Orchestrator:** A utility to start/stop the server binary with custom environment variables (e.g., `DATABASE_URL`, `SERVER_CONFIG_PATH`). 2. **Test Runner:** Leverage `tokio::test` and the SDK's `Client`. 3. **Verification:** - Perform an action via SDK. - Verify the API response. - (Optional) Verify the side-effect directly in the database using `sqlx`. - (Optional) Verify the corresponding event was received on a Gateway stream. ## Task List - [ ] Scaffold `integration-tests/` crate and workspace configuration. - [ ] Implement a `TestServer` helper that manages the server process and temporary SQLite database. - [ ] Implement base test setup: Identity generation and SDK Client initialization. - [ ] Phase 1: Authentication tests. - [ ] Phase 2: Channel and Message CRUD tests. - [ ] Phase 3: Permissions and Roles tests (verifying `open`/`private`/`strict` behaviors). - [ ] Phase 4: Gateway event verification. - [ ] Phase 5: Attachment and Media tests. - [ ] Integrate with CI (GitHub Actions) to run integration tests on PRs. ## Test List - [ ] `test_auth_flow`: Complete challenge-response and session token acquisition. - [ ] `test_message_send_receive`: Send a message via REST, verify it appears in history and arrives via Gateway. - [ ] `test_permission_enforcement`: Attempt unauthorized actions and verify 403 responses. - [ ] `test_multi_server_config`: Run a standard test suite against all three default configs. ## Open Questions - Should we use a tool like `testcontainers` or stick to spawning local processes for simplicity? (Recommendation: Start with local processes for faster feedback). - How to handle WebRTC/Media testing in integration? (Recommendation: Out of scope for phase 1; focus on REST/Gateway first). - Should this be a separate crate or live in `server/tests/`? (Recommendation: Separate crate to ensure it only uses the public API/SDK).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feature/115-chatbot-2
feature/16-dms
gh-pages
No results found.
Labels
Clear labels   
area:api
Backend endpoints, REST, DB, Gateway

  
area:core
Shared Rust logic, crypto, Tauri shell

  
area:docs
Documentation, OpenAPI specs, architecture

  
area:infra
Deployment, Docker, build tools

  
area:ux
Frontend UI, React components, Tailwind

  
dependencies
Pull requests that update a dependency file

  
documentation
Improvements or additions to documentation

  
duplicate
This issue or pull request already exists

  
good first issue
Good for newcomers

  
help wanted
Extra attention is needed

  
invalid
This doesn't seem right

  
question
Further information is requested

  
rust
Pull requests that update rust code

  
status:complete
Feature fully implemented

  
status:partial
Partially implemented (server done, client pending)

  
status:planned
Not yet started

  
type:bug
Bug fixes

  
type:design
Architectural changes, major design decisions

  
type:feature
New features

  
type:infra
Infrastructure and CI/CD changes

  
type:refactor
Code improvements without behavioral changes

  
type:research
Spikes, investigating new tech

  
type:ux
User experience improvements

  
wontfix
This will not be worked on

No labels
area:api
area:core
area:docs
area:infra
area:ux
dependencies
documentation
duplicate
good first issue
help wanted
invalid
question
rust
status:complete
status:partial
status:planned
type:bug
type:design
type:feature
type:infra
type:refactor
type:research
type:ux
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
icub3d/decentcom#67
No description provided.