This repository contains integration tests for OpenXAPI-generated SDKs to ensure they work correctly with each release.
This repository serves as a comprehensive test suite for all SDKs generated by OpenXAPI. It validates that the generated code functions correctly against real exchange APIs, ensuring reliability and compatibility across different exchanges, languages, and protocols.
The repository follows a strict hierarchical structure:
src/
└── {exchange}/
└── {language}/
└── {protocol}/
└── {module}/
Where:
{exchange}
: The cryptocurrency exchange (e.g.,binance
,okx
,bybit
){language}
: The programming language (e.g.,go
,python
,javascript
){protocol}
: The protocol type (ws
for WebSocket,rest
for REST API){module}
: The specific trading module (e.g.,spot
,umfutures
,cmfutures
)
src/
└── binance/ # Binance exchange tests
└── go/ # Go language tests
├── ws/ # WebSocket API tests
│ ├── spot/ # Spot WebSocket API + User Data Streams
│ ├── umfutures/ # USD-M Futures WebSocket API + User Data Streams
│ ├── cmfutures/ # Coin-M Futures WebSocket API + User Data Streams
│ ├── options/ # Options WebSocket API + User Data Streams
│ ├── pmargin/ # Portfolio Margin WebSocket API + User Data Streams
│ ├── spot-streams/ # Spot Market Data Streams (public data)
│ ├── umfutures-streams/ # USD-M Futures Market Data Streams (public data)
│ ├── cmfutures-streams/ # Coin-M Futures Market Data Streams (public data)
│ └── options-streams/ # Options Market Data Streams (public data)
└── rest/ # REST API tests
└── spot/ # Spot trading REST API tests (87.2% coverage)
-
Module Isolation: Each integration test folder is completely independent. When working on tests:
- Only modify files within your dedicated module folder
- Do not change files in other modules or exchanges
- Each folder represents a specific
{exchange}/{language}/{protocol}/{module}
combination
-
SDK Location: The SDKs being tested are located outside this repository:
- WebSocket APIs + User Data Streams:
../binance-go/ws/{module}
(e.g.,../binance-go/ws/spot
) - Market Data Streams:
../binance-go/ws/{module}-streams
(e.g.,../binance-go/ws/spot-streams
) - REST APIs:
../binance-go/rest/{module}
(e.g.,../binance-go/rest/spot
) - Never modify SDK source files - only create integration tests
- WebSocket APIs + User Data Streams:
-
Adding New Integration Tests:
- Follow the exact directory structure:
src/{exchange}/{language}/{protocol}/{module}/
- Create all necessary test files within your module folder
- Include a README.md specific to your module
- Add appropriate
.gitignore
andenv.example
files
- Follow the exact directory structure:
- Navigate to the specific module directory
- Set up environment variables:
cd src/binance/go/ws/spot cp env.example env.local # Edit env.local with your API credentials source env.local
By default, tests are run against the testnet server where available.
# Spot WebSocket API + User Data Streams (41 endpoints, 100% coverage)
cd src/binance/go/ws/spot
go test -v -run TestFullIntegrationSuite ./...
# USD-M Futures WebSocket API + User Data Streams (19 endpoints, 100% coverage)
cd src/binance/go/ws/umfutures
go test -v -run TestFullIntegrationSuite ./...
# Coin-M Futures WebSocket API + User Data Streams (10 endpoints, 100% coverage)
cd src/binance/go/ws/cmfutures
go test -v -run TestFullIntegrationSuite ./...
# Options WebSocket API + User Data Streams (3 endpoints, 100% coverage)
cd src/binance/go/ws/options
go test -v -run TestFullIntegrationSuite ./...
# Portfolio Margin WebSocket API + User Data Streams (11 event types, limited coverage)
cd src/binance/go/ws/pmargin
go test -v -run TestFullIntegrationSuite ./...
# Spot Market Data Streams (10 stream types, 100% coverage)
cd src/binance/go/ws/spot-streams
go test -v -run TestFullIntegrationSuite ./...
# USD-M Futures Market Data Streams (13 stream types, 100% coverage)
cd src/binance/go/ws/umfutures-streams
go test -v -run TestFullIntegrationSuite ./...
# Coin-M Futures Market Data Streams (13 stream types, 100% coverage)
cd src/binance/go/ws/cmfutures-streams
go test -v -run TestFullIntegrationSuite ./...
# Options Market Data Streams (9 stream types, 100% coverage)
cd src/binance/go/ws/options-streams
go test -v -run TestFullIntegrationSuite ./...
# Spot REST API (410+ endpoints, 87.2% coverage)
cd src/binance/go/rest/spot
go test -v -run TestFullIntegrationSuite ./...
Tests for request/response style WebSocket APIs and user-specific data streams:
- Public Endpoints: Market data, exchange info, ticker prices (no auth required)
- Trading Endpoints: Order placement, cancellation, modification (TRADE auth)
- Account Endpoints: Balance queries, position info, trading status (USER_DATA auth)
- Session Management: Authentication, connection lifecycle
- User Data Streams: Account updates, order updates, position changes (authenticated)
- Authentication Methods: HMAC, RSA, Ed25519 signature support
Tests for real-time public market data streaming WebSocket APIs:
- Market Data Streams: Trade, ticker, depth, kline streams (no auth required)
- Combined Streams: Multi-stream subscriptions and event handling
- Connection Management: Server selection, reconnection, error handling
- Subscription Management: Dynamic subscribe/unsubscribe operations
- Event Processing: Real-time event handling and data validation
Tests for traditional HTTP REST APIs:
- Public APIs: Market data, exchange information
- Trading APIs: Order management, trade execution
- Account APIs: Balance queries, transaction history
- Wallet APIs: Deposits, withdrawals, transfers
- Advanced Features: Margin trading, staking, mining, loans
- Total Modules: 10 (9 WebSocket + 1 REST)
- WebSocket API + User Data Streams Modules: 5 (spot, umfutures, cmfutures, options, pmargin)
- Market Data Streams Modules: 4 (spot-streams, umfutures-streams, cmfutures-streams, options-streams)
- REST API Modules: 1 (spot)
- Overall Coverage: Comprehensive across all major Binance trading products
- Authentication: All three methods (HMAC, RSA, Ed25519) where supported
- Error Handling: Comprehensive error scenarios and recovery testing
- Rate Limiting: Proper handling of exchange rate limits
- Real-time Data: Live market data validation and event processing
- Cross-platform: Tests run on testnet and mainnet environments
- Performance: Load testing and concurrent operations
- Event Handlers: Updated to use
HandleXxxEvent
naming pattern (replacedOnXxxEvent
)
- Testnet: Primary testing environment (safe for most tests)
- Mainnet: Required for Options and Portfolio Margin (no testnet available)
- Authentication: API keys and secrets required for private endpoints
- Network: Stable internet connection required for real-time tests
Each module includes:
env.example
- Template for environment variablesREADME.md
- Module-specific documentation and usage instructionsAPI_COVERAGE.md
- Detailed test coverage tracking- Comprehensive test suites with error handling and logging
All WebSocket integration tests have been updated to use the new SDK naming pattern:
- Event Handlers:
OnXxxEvent
→HandleXxxEvent
- Affected Modules: All WebSocket streams modules (spot-streams, umfutures-streams, cmfutures-streams, options-streams)
- WebSocket API Modules: Updated to use
HandleXxxEventEvent
pattern with proper model types - Status: ✅ All modules now compile and run successfully with updated patterns
// OLD pattern (no longer used)
client.OnAggregateTradeEvent(func(event *models.AggregateTradeEvent) error {
return nil
})
// NEW pattern (current)
client.HandleAggregateTradeEvent(func(event *models.AggregateTradeEvent) error {
return nil
})
- Integration tests interact with real exchange endpoints
- Use testnet environments when available to avoid affecting real trading
- Some tests may require specific account permissions or balances
- Rate limits apply - tests include appropriate delays
- Tests include comprehensive logging for debugging and monitoring
When adding new integration tests:
- Follow the existing directory structure:
src/{exchange}/{language}/{protocol}/{module}/
- Include appropriate environment variable handling and security
- Add comprehensive error checking and timeout management
- Create detailed API coverage documentation
- Include both positive and negative test scenarios
- Update this README with new module information
- Ensure tests are idempotent and can be run repeatedly