Test

Class: Test

sqlanvil test actions can be used to write unit tests for your generated SQL

You can create unit tests in the following ways.

Using a SQLX file:

-- definitions/name.sqlx
config {
  type: "test"
}

input "foo" {
  SELECT 1 AS bar
}

SELECT 1 AS bar

Using the Javascript API:

definitions/file.js

test("name")
  .input("sample_data", `SELECT 1 AS bar`)
  .expect(`SELECT 1 AS bar`);

publish("sample_data", { type: "table" }).query("SELECT 1 AS bar")

Note: When using the Javascript API, methods in this class can be accessed by the returned value. This is where input and expect come from.

Naming the test:

By default a test in a SQLX file is named after its file: definitions/name.sqlx creates a test called name. Set name in the config to override that. A test creates nothing in the warehouse, so the name is only its label: sqlanvil test reports each result as <name>: passed or <name>: failed. The action under test is set by dataset, not by the name:

-- definitions/tests/sample_data.sqlx
config {
  type: "test",
  dataset: "sample_data",
  name: "sample_data_returns_one"
}

SELECT 1 AS bar

In the Javascript API the name is the first argument to test().

Hierarchy

• ActionBuilder‹Test›

  ↳ Test

Index

Methods

• dataset
• expect
• input

Methods

dataset

▸ dataset(ref: Resolvable): this

Sets the schema (BigQuery dataset / Postgres schema) in which to create the output of this action.

Parameters:

Name	Type
ref	Resolvable

Returns: this

---

expect

▸ expect(contextableQuery: Contextable‹IActionContext, string›): this

Sets the expected output of the query to being tested against.

Parameters:

Name	Type
contextableQuery	Contextable‹IActionContext, string›

Returns: this

---

input

▸ input(refName: string | string[], contextableQuery: Contextable‹IActionContext, string›): this

Sets the input query to unit test against.

Parameters:

Name	Type
refName	string | string[]
contextableQuery	Contextable‹IActionContext, string›

Returns: this