
Testing
- 43 installs
- 3.3k repo stars
- Updated August 3, 2026
- bytebase/dbhub
Run, write, and troubleshoot DBHub tests, including unit tests and Testcontainers-based database integration tests with Docker.
About
Documents DBHub's test commands and how to run, filter, and debug unit and Docker-backed integration tests. A developer uses it to run tests, fix failures, or add coverage when verifying DBHub changes.
- pnpm test unit and integration commands, watch mode, name-pattern filtering
- Covers Testcontainers integration tests and Docker/container troubleshooting
Testing by the numbers
- 43 all-time installs (skills.sh)
- Ranked #1,252 of 2,153 Testing & QA skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/bytebase/dbhub --skill testingAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 43 |
|---|---|
| repo stars | ★ 3.3k |
| Last updated | August 3, 2026 |
| Repository | bytebase/dbhub ↗ |
What it does
Run, write, and troubleshoot DBHub tests, including unit tests and Testcontainers-based database integration tests with Docker.
Files
Testing Skill
This skill helps you run, write, and troubleshoot tests in the DBHub project.
Test Commands
pnpm test # Run all tests (unit + integration)
pnpm test:unit # Unit tests only (no Docker needed)
pnpm test:watch # Interactive watch mode
pnpm test:integration # Integration tests only (requires Docker)Run a specific test file:
pnpm test src/connectors/__tests__/postgres.integration.test.ts
pnpm test src/utils/__tests__/allowed-keywords.test.tsRun tests matching a name pattern:
pnpm test -- --testNamePattern="PostgreSQL"Verbose output for debugging:
pnpm test:integration --reporter=verboseTest Architecture
Vitest is configured with two projects in vitest.config.ts:
- unit: All
*.test.tsfiles excluding*integration*in the filename - integration: Only
*integration*.test.tsfiles
This means the naming convention matters — integration tests MUST have integration in their filename to be correctly categorized.
Test File Locations
Unit tests (~20 files, no Docker needed):
src/utils/__tests__/— Utility function tests (SQL parsing, DSN obfuscation, SSH config, allowed keywords, identifier quoting, parameter mapping, row limiting, safe URL, config watcher, AWS RDS signer)src/tools/__tests__/— Tool handler tests (execute-sql, search-objects, custom-tool-handler)src/config/__tests__/— Configuration tests (env parsing, TOML loading)src/connectors/__tests__/— Connector unit tests (dsn-parser, manager)src/requests/__tests__/— Request store tests
Integration tests (~11 files, Docker required):
src/connectors/__tests__/postgres.integration.test.tssrc/connectors/__tests__/mysql.integration.test.tssrc/connectors/__tests__/mariadb.integration.test.tssrc/connectors/__tests__/sqlserver.integration.test.tssrc/connectors/__tests__/sqlite.integration.test.tssrc/connectors/__tests__/postgres-ssh.integration.test.tssrc/connectors/__tests__/multi-sqlite-sources.integration.test.tssrc/__tests__/json-rpc-integration.test.tssrc/api/__tests__/sources.integration.test.tssrc/api/__tests__/requests.integration.test.tssrc/config/__tests__/ssh-config-integration.test.ts
IntegrationTestBase
Database connector integration tests extend IntegrationTestBase<TContainer> from src/connectors/__tests__/shared/integration-test-base.ts. This abstract class provides:
- Lifecycle: Container start in
beforeAll(120s timeout) → connect → setup test data → run tests → cleanup inafterAll - Shared test suites:
createConnectionTests(),createSchemaTests(),createTableTests(),createSQLExecutionTests(),createStoredProcedureTests(),createCommentTests(),createErrorHandlingTests() - Standard test data:
userstable (id, name, email, age) +orderstable (id, user_id, amount) +test_schema.products
To add a new database connector test, extend this class and implement:
createContainer()— Start the Testcontainers instancecreateConnector()— Create the database connectorsetupTestData(connector)— Populate test tables
Test Fixtures
Located in src/__fixtures__/:
helpers.ts— Utilities:fixtureTomlPath(),loadFixtureConfig(),setupManagerWithFixture()toml/multi-sqlite.toml— Three in-memory SQLite databases (database_a, database_b, database_c)toml/readonly-maxrows.toml— Sources with readonly/max_rows tool configurations
Usage:
import { setupManagerWithFixture, FIXTURES } from '../../__fixtures__/helpers.js';
const manager = await setupManagerWithFixture(FIXTURES.MULTI_SQLITE);
// ... test ...
await manager.disconnect();Mocking Patterns
Unit tests use vitest mocking:
vi.mock('../../connectors/manager.js'); // Mock ConnectorManager
vi.mocked(ConnectorManager.getCurrentConnector).mockReturnValue(mockConnector);SSH tunnel tests mock SSHTunnel.prototype.establish to avoid real SSH connections while testing config passing.
Integration Testing
Integration tests use Testcontainers to run real database instances in Docker.
Prerequisites
Before running integration tests: 1. Docker is installed and running: docker ps 2. Sufficient Docker memory (4GB+ recommended, especially for SQL Server) 3. Network access to pull Docker images
Database Images
| Database | Image | Notes |
|---|---|---|
| PostgreSQL | postgres:15-alpine | Fast startup |
| MySQL | @testcontainers/mysql | Supports IAM auth testing |
| MariaDB | @testcontainers/mariadb | Supports IAM auth testing |
| SQL Server | @testcontainers/mssqlserver | Slow startup (3-5 min), needs 4GB+ RAM |
| SQLite | No container needed | In-memory or file-based |
Troubleshooting
Container Startup Failures
docker ps # Verify Docker is running
docker system df # Check disk space
docker pull postgres:15-alpine # Manually pull imagesSQL Server Timeouts
SQL Server containers are the slowest to start (3-5 minutes). Run them separately and ensure Docker has 4GB+ memory:
pnpm test src/connectors/__tests__/sqlserver.integration.test.tsTest Isolation Issues
Each integration test manages its own container lifecycle. If containers leak, clean up:
docker ps -a | grep testcontainers # Find leaked containers
docker container prune # Clean up stopped containersCI Failures
The CI workflow (.github/workflows/run-tests.yml) runs unit and integration tests as separate parallel jobs on PR events. Unit tests don't need Docker; integration tests verify Docker availability first. Check the specific job that failed.
Adding New Tests
Unit test: Create src/{module}/__tests__/{name}.test.ts — will auto-run with pnpm test:unit.
Integration test: Create src/{module}/__tests__/{name}.integration.test.ts — the integration in the filename is what routes it to pnpm test:integration.
New connector test: Extend IntegrationTestBase, implement the three abstract methods, and call the shared test suite methods.