Skip to content

test: add SDK-focused integration tests and expand CLI smoke #9

Description

@dapi

Summary

Current CI validates unit tests and a narrow CLI smoke path (send --parse-mode).
For this project, we need stronger confidence in SDK-level behavior and real command wiring.

Why

  • Most tests are mocked unit tests around telegram-client methods.
  • No integration suite that validates MCP SDK tool wiring end-to-end in a controlled environment.
  • CLI smoke currently checks only parse-mode validation and misses core command surfaces.

Scope

  1. Add an SDK-focused integration test suite.
  2. Expand CLI smoke checks in CI with deterministic, non-network scenarios.

Proposed implementation

1) Integration tests (new tests/integration/)

  • Start MCP server in test mode with temporary TGCLI_STORE.
  • Verify MCP tool registration and call path for:
    • listChannels
    • searchChannels
    • getChannelMessages
    • scheduleMessageSync
    • listMessageSyncJobs
  • Use controlled mocks/fixtures for MTProto boundaries, but keep server + tool execution real.
  • Validate response schemas and error contracts.

2) CLI smoke expansion (CI)

  • Keep existing parse-mode checks.
  • Add deterministic smoke checks for:
    • tgcli --help
    • tgcli <group> --help for key command groups (sync, messages, channels, send, server, config)
    • invalid argument handling and exit codes
    • temp-store config read/write (TGCLI_STORE=$(mktemp -d))
  • Ensure no external Telegram network dependency in smoke job.

3) CI structure

  • Split test scripts:
    • npm run test:unit
    • npm run test:integration
    • npm run test:smoke
  • Update CI workflow to run all three and fail fast on contract regressions.

Acceptance criteria

  • Integration tests run in CI and validate MCP SDK tool execution path.
  • CLI smoke covers all major command groups + exit code expectations.
  • No integration/smoke step requires real Telegram account or network login.
  • CI stays under an acceptable runtime budget (target: < 5 minutes total).

Notes

Primary quality gate should be SDK behavior correctness, not only method-level units.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions