Skip to main content

​
Test suite overview

DevPixelForge has 316+ tests spread across three categories:
ComponentTypeCountLocation
Rust operationsUnit (inline)280+dpf/src/*/tests
Rust pipelineIntegration20+dpf/tests/integration_tests.rs
Go bridgeUnit + integration16+go-bridge/dpf_test.go
Total—316+—

​
Running tests

The make test target builds the Rust binary and verifies it by running dpf caps:
make test
This is a smoke test — it confirms the binary compiled correctly and its capability report is valid. For the full test suite, run Rust and Go tests directly.

​
Test fixtures

The Rust test suite uses a set of pre-generated image fixtures. Generate them with: 
cd dpf && cargo run --example gen_fixtures
This writes the following files to dpf/test_fixtures/:
FixtureDescription
sample.pngRGBA 100×100 gradient
sample.jpgJPEG 100×100
sample.svgSVG vector 100×100
sample_transparent.pngPNG with alpha channel
large.png1000×1000 PNG
solid_red.pngSolid red fill
solid_blue.pngSolid blue fill
corrupt/bad.pngCorrupt file for error-path tests

​
Parallel execution and slow tests

Cargo runs tests in parallel by default. You can control the thread count: 
cd dpf && cargo test -- --test-threads=8
AVIF encoding is CPU-intensive and significantly slower than other format tests. Skip it during rapid iteration: 
cd dpf && cargo test -- --skip avif

​
Troubleshooting

“Binary not found” in Go tests The Go bridge tests look for the dpf binary at a path relative to the repo root. Build the Rust binary first: 
cd dpf && cargo build
cd go-bridge && go test -v
Missing fixtures If the integration tests fail with missing file errors, regenerate the fixtures: 
cd dpf && cargo run --example gen_fixtures
Tests are slow on first run The first cargo test compiles all dev-dependencies (including tempfile and assert_fs). Subsequent runs use the incremental cache and are much faster.

Build docs developers (and LLMs) love

Get started for freeTalk to us