run-tests

Build, run, and debug the LPTS SQL transpilation test suite.

8|1|Updated Mar 4, 2026
One-click install
npx skills add https://github.com/cwida/lpts --skill run-tests-cwida
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: run-tests
Source: https://github.com/cwida/lpts/tree/main/.claude/skills/run-tests
Command: npx skills add https://github.com/cwida/lpts --skill run-tests-cwida

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Manually building the LPTS extension, running test suites, tracking assertion results, and diagnosing test crashes or transpilation failures is time-consuming and prone to oversight, especially when iterating on new features or dialect support.

Core Features & Use Cases

  • Automated Test Execution: Builds the LPTS extension if needed, runs the full test suite or targeted individual test files in a single workflow.
  • Clear Result Reporting: Returns exact counts of passed and failed assertions, and surfaces failing test names with expected vs actual output for quick issue identification.
  • Guided Debugging: Provides step-by-step troubleshooting steps for test crashes, unsupported query errors, and AST/logical plan inspection to resolve transpilation edge cases.
  • Use Case: When adding support for a new SQL dialect in LPTS, use this Skill to run the full regression test suite to confirm existing functionality remains intact, and debug any failing transpilation cases for the new dialect.

Quick Start

Use the run-tests skill to run the full LPTS test suite and get a summary of all passed and failed assertions.

Frequently Asked Questions about run-tests

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I automate DuckDB test suite execution for SQL transpilation regression testing?

Automate DuckDB test suite execution by building the LPTS extension and running targeted test files to verify SQL transpilation regression. The workflow returns exact passed and failed assertion counts, surfacing failing test names with expected versus actual output for quick identification.

What is the best way to debug unsupported query patterns causing test crashes during dialect compatibility validation?

Debug unsupported query patterns causing test crashes using guided troubleshooting steps for AST and logical plan inspection. This approach resolves transpilation edge cases encountered during dialect compatibility validation by identifying exact query failures.

Do I need the LPTS repository build tools to run regression tests for new SQL dialect features?

You need the LPTS repository build tools and DuckDB test runner to execute regression tests for new SQL dialect features. Optional TPC-H and SQL Storm test datasets provide comprehensive test coverage for validating query correctness.

How does automated test reporting identify expected versus actual output for failing SQL assertions?

Automated test reporting identifies failing SQL assertions by returning exact counts of passed and failed assertions, then surfacing failing test names with expected versus actual output. This clear result reporting enables quick issue identification during test debugging.

Why does running individual test files help with crash investigation for unsupported query patterns?

Running individual test files helps with crash investigation for unsupported query patterns by isolating specific transpilation failures. This targeted execution avoids rebuilding the entire suite, streamlining the identification of unsupported query errors.

Can I use TPC-H and SQL Storm datasets for comprehensive query correctness validation in DuckDB?

You can use TPC-H and SQL Storm datasets for comprehensive query correctness validation in DuckDB. These optional test datasets expand test coverage to ensure robust SQL transpilation across various dialect compatibility scenarios.