---
title: "Naming conventions"
description: "How names and synonyms work across all definition sources"
url: "https://docs.justcat.it/reference/project-file/naming-conventions/"
---
# Naming conventions


The documentation names each property in one canonical form — the [test](https://docs.justcat.it/reference/tests/properties/ "Test properties") reference calls one of them `Test suite`, for example. That is not the only accepted spelling, and for some properties not the only accepted name. CAT matches property names against a set of synonyms, and the match is not case sensitive.

## Why synonyms exist

Definitions do not only live in the project file. They live in database tables, in stored procedure result sets, in worksheets, in other YAML files — see [Lists](https://docs.justcat.it/reference/project-file/lists/ "Lists"). Each of those has its own naming culture:

* in PostgreSQL an unquoted identifier is folded to lower case, so a column is naturally `test_suite`; naming it `TestSuite` means quoting it everywhere and working against the language;
* a worksheet header or a report column reads as `Test Suite`, with a space;
* YAML written by hand next to application code is often `TestSuite`.

Matching by synonym means no source has to adopt a naming style that is unnatural for it. You keep the convention your team and your storage already use, and CAT reads it.

## Accepted forms

For every documented property name, three written forms are accepted:

| Written form | Example | Notes |
|---|---|---|
| With spaces | `Test Suite` | The canonical form used in this documentation |
| With underscores | `Test_Suite` | Spaces replaced by underscores |
| Without separators | `TestSuite` | Spaces removed |

Casing is free on top of that, so `tEsT sUiTe` and `TEST_SUITE` are both understood. Whitespace around the name is ignored.

Some properties answer to more than one name, and each of those names accepts all three forms. `Test suite` is also just `Suite`; a test's name is `Name` or `Test name`; a timeout is `Timeout` or `Timeout in seconds`. The property reference pages list the names each property answers to.

The same applies to the top-level keys of the project file. `Get list of tests from` is also matched as `Get_List_of_Tests_from` and `GetListOfTestsFrom`.

> **🐱:** <a href="https://www.freecodecamp.org/news/snake-case-vs-camel-case-vs-pascal-case-vs-kebab-case-whats-the-difference/" target="_blank">Kebab case</a> (`test-suite`) is **not** matched. If you need it, let us know — it is easy to add.



## Where the matching applies

Property names are matched the same way wherever the definition comes from: keys in the project file, keys in other YAML files, column names returned by a database query or a stored procedure, header cells in a worksheet or a CSV file.

Each property is matched on its own, so different definitions do not have to agree on a style — a list of tests read from PostgreSQL can use `test_suite`, or even `suite`, while the tests written in the project file use `Test suite`. Within one document, staying with a single style is still worth it for whoever reads the file next.

> **🐱:** Insensitivity applies to what CAT reads, not to what CAT sends. Queries and connection strings are handed to the provider exactly as written, and the provider may well be case sensitive.



