Skip to content

Examples

The examples/ folder of the repository holds BigTesty projects you can run as they are. Each one has its bigtesty.yaml, its tests and a README, and runs in the CI of BigTesty on a real BigQuery.

Example What it shows Command
Queries test data from a file or inline, a query file or an inline query, expected rows from a file or inline, compare_columns: expected_only bigtesty test --config examples/01-queries/bigtesty.yaml
Assertion functions Python functions checking the query result, a row count, an inline table schema bigtesty test --config examples/02-assertion-functions/bigtesty.yaml
MERGE with DDL a when step running a MERGE script, a view created by a DDL file, assertions on a table and a query, key_columns bigtesty test --config examples/03-merge-with-ddl/bigtesty.yaml
uv project BigTesty as a uv dev dependency from PyPI, one pytest test per scenario, CI with GitHub Actions, GitLab CI and Cloud Build uv run pytest, from its folder
Python tests Python code writing to BigQuery, tested with pytest and unittest on one infra created in a setup and deleted in a teardown pytest examples/05-python-tests --bigtesty-config examples/05-python-tests/bigtesty.yaml
Production SQL the production SQL tested as is from src/: a Jinja template rendered by the rendering code of the production, query parameters bigtesty test --config examples/06-production-sql/bigtesty.yaml

Run them from the repository root, with Application Default Credentials and the roles/bigquery.user role on the test project:

Terminal window
gcloud auth application-default login
export GOOGLE_CLOUD_PROJECT=<gcp_project_id>

From a clone of the repository, prefix the commands with uv run to use BigTesty from the sources. The example 06 needs jinja2, a dev dependency of the repository. Every scenario runs on its own datasets, deleted at the end of the run: nothing to clean up.

  • The production SQL, not a copy. sql_file points to the SQL of src/, and project_aliases rewrites the references to the production project (06).
  • The template engine of the team. The sql_renderer calls the rendering code of the production: a broken macro or a missing var fails the tests too (06).
  • Expected rows written by BigTesty. Write the query, run bigtesty test --update and review the diff of the expected files (01).
  • One infra for several tests. A class or module scoped fixture creates the infra once, reset() empties the tables between the parametrized scenarios (05).
  • BigTesty locked like any dev dependency. uv add --dev bigtesty, and the CI runs uv run pytest with the version of uv.lock (04).

The bigtesty-java-example repository, separate to keep Maven out of this one, tests Java code writing to BigQuery with JUnit 5: an extension creating the infra before all the tests of a class and destroying it after them, with the CLI or the Docker image run with Testcontainers (mvn test -Dbigtesty.runner=docker). See Other languages for the CLI contract.