Yaml@1

Yaml@1 provider allows you to test data in YAML files. It is more useful for loading test definitions and other CAT configurations.

Example - testing data

Data Source Definition

Let’s say you have a YAML file with data you want to test. This way you define one YAML file as a data source and give it friendly name “DepartmentData”:

Data Sources:
- Name: DepartmentData
  Provider: Yaml@1
  Connection string: ./DepartmentData.yaml

Test Definition

In the tests you can define your expectations about the data in the file.

Tests:
- Name: Check number of generated  records
  Data Source: DepartmentData
  Query: /Departments # define path to data here using slashes
  Expectation: set row count
  Expected row count: 10

Notice the Query - you can NOT issue SQL queries against YAML data. Instead, provide a path to the data. If you want retrieve department data from a YAML file that looks like this:

Date: 2023-05-02
Company: ABC
Structure:
    Departments:
    - Name: Sales
    - Name: Marketing
    - Name: HR

you need to provide /Structure/Departments to the Query. CAT will iterate the list and return a resultset with one column (Name) and three rows.

Example - Test definitions

You can use YAML for defining your tests and data sources. You can define both in your Project file - in that case you don’t need to care about anything. But over time, you project file will become bigger and bigger, and less manageable. You can easily split it and instruct CAT to load tests from other YAML files, like this:

Get list of tests from:
- Provider: Yaml@1
  Name: Smoke tests # list of tests have optional name, useful for troubleshooting
  Connection string: ./SmokeTests.yaml # relative paths are resolved against directory where is your project file
  Query: /SmokeTests
- Provider: Yaml@1
  Name: Integrity checks
  Connection string: ./IntegrityChecks.yaml
  Query: /IntegrationChecks
# - ...  abbreviated

Or if you don’t have too many tests, you can use this technique for splitting tests inside your project file (just specify you project file name in the data source definition).

YAML / JSON

YAML is superset of JSON. Simply said, you can use JSON inside YAML files and it will be valid. Use it to your advantage.

Examples:

# define empty array:
Expected Data: []
# array with data:
Other Data: ["Red", "Green", "Blue"]
# define object with JSON syntax:
Expected Employee: { "First name": "Tereza", "Last name": "Černá", "Department": "Testing" }

The above example is a valid YAML document. JSON offers more concise expression of hardcoded data. It is also much easier to autogenerate them.

Example - hardcoded data

You may have a need to hardcode some data and then e.g., compare result from a query from a relational data source with those data. Yaml@1 comes in handy in that case:

Data sources:
- Name: ExpectedData
  Provider: Yaml@1
  Connection string: ./MyCatProject.cat.yaml # name of the project file or other file where you have the data

Tests:
- Name:
  Description: Sample dataset contains problems for two invoices, the test should identify them
  First Data Source: Accounting
  First Query: SELECT InvoiceID FROM fn_GetProblematicInvoices();
  Second Data Source: ExpectedData
  Second Query: /Expected data

Expected data:
- InvoiceID: 202000483490
- InvoiceID: 202330409494

Remarks

Yaml@1 provider is capable of reading data from single node only, with no depth settings. It cannot combine data from the collection it is itterating with its parrents nor children. Primary design goal was to use it as a simple way to load definitions of tests.

← SqlServer@2
Introduction →