Unit Testing Overview

Unit testing in the pmm-dump project ensures the reliability of core utility functions, data source interactions, and security measures. These tests are distinct from end-to-end (e2e) tests as they focus on individual components without requiring the full PMM environment stack, although some utilize mock HTTP servers for network interaction testing.

The project utilizes standard Go testing tools and the testify library for assertions. Unit tests are executed via a Makefile shortcut make run-unit-tests, providing a fast feedback loop for developers compared to the more resource-intensive e2e suite.
Sources: README.md:120, internal/test/README.md:16

Test Categories and Architecture

The unit testing suite is organized into functional areas reflecting the tool's architecture. Key areas include utility validation, security/redaction, and data source specific logic.

Utility and Configuration Testing

Tests in pkg/util/util_test.go and cmd/pmm-dump/util_test.go validate the logic for environment variable parsing and configuration fallback. This ensures that the tool correctly constructs connection strings (URLs) for VictoriaMetrics, ClickHouse, and PostgreSQL, even when provided with fragmented configuration components.
Sources: pkg/util/util_test.go:21-82, cmd/pmm-dump/util_test.go:50-67

Security and Redaction

Security tests ensure that sensitive information like passwords and tokens are never leaked in logs, process lists, or the resulting dump metadata.

• URL Redaction: Validates that credentials in connection strings are replaced with ***:***.
• File Permissions: Ensures created dump files have restricted permissions (0o600).
• Process List Safety: Checks that secrets passed via environment variables do not appear in /proc/<pid>/cmdline.
  Sources: cmd/pmm-dump/security_test.go:28-100, cmd/pmm-dump/util_test.go:25-48

Data Source Logic

Components interacting with external databases use httptest.NewServer to mock the behavior of VictoriaMetrics or ClickHouse. For example, TestWriteChunk in VictoriaMetrics tests how the source handles content limits and native data formats by simulating a PMM server's response.
Sources: pkg/victoriametrics/source_test.go:42-120

Execution Flow

The following diagram illustrates the flow of a standard unit test that involves a mocked network component:

The flow shows how internal project logic is decoupled from a live PMM server by using local mock servers during the testing phase.
Sources: pkg/victoriametrics/source_test.go:70-117

Summary of Unit Test Components

Sources: pkg/util/util_test.go:21, cmd/pmm-dump/security_test.go:30, pkg/victoriametrics/source_test.go:42

Code Example: Mocking and Assertion

Unit tests frequently use the testify/assert and testify/require packages to validate expectations. Below is a simplified pattern derived from the VictoriaMetrics source testing:

// From pkg/victoriametrics/source_test.go:70-117
server := httptest.NewServer(http.HandlerFunc(func(rw http.ResponseWriter, req *http.Request) {
    if req.ContentLength > int64(tt.contentLimit) && tt.contentLimit != 0 {
        rw.WriteHeader(http.StatusRequestEntityTooLarge)
        return
    }
    // ... read and decompress metrics ...
}))
defer server.Close()

grafanaC, _ := client.NewClient(httpC, authParams)
s := NewSource(grafanaC, Config{ConnectionURL: server.URL})

err := s.WriteChunk("", bytes.NewBuffer(data))
// Assertions
if tt.shouldErr {
    assert.Error(t, err)
} else {
    assert.NoError(t, err)
}

Sources: pkg/victoriametrics/source_test.go:70-117

Unit testing serves as the first line of defense in pmm-dump, specifically protecting against regressions in configuration parsing and credential security before code reaches the integration-heavy e2e testing stage.