Test Case Naming Conventions - SatelliteQE/robottelo GitHub Wiki

Test case naming conventions

Robottelo test names should make the expected behavior obvious from the module and function name alone.

File names

Test modules follow:

test_<feature>.py

Examples:

  • test_activationkey.py
  • test_repository.py
  • test_install_foremanctl.py

Test function naming

The most common patterns in the repository are:

Pattern Use for
test_positive_<action>_<entity> expected success path
test_negative_<action>_<entity> expected failure or validation path
test_post_<action>_<entity> post-upgrade verification

Examples:

  • test_positive_create_with_name
  • test_negative_create_with_invalid_name
  • test_positive_check_installer_hammer_ping
  • test_post_upgrade_fdi_version

Why the naming pattern matters

These names are not only for style. Consistent naming makes it much easier to:

  • scan large modules quickly
  • understand the expected outcome before reading the body
  • spot duplicate or overlapping tests
  • filter mentally between happy-path, negative, and upgrade coverage

Naming guidance

  • Put the behavior first, not the implementation detail.
  • Prefer clear entity names over abbreviations unless the abbreviation is already common in the codebase.
  • Add suffixes such as with_<condition>, by_<selector>, or using_<path> when they improve clarity.
  • Keep names stable unless the test intent materially changes.

Good examples

  • test_positive_create_with_name
  • test_negative_create_with_invalid_name
  • test_positive_delete_by_id

Less helpful examples

  • test_create_1
  • test_foo
  • test_ui_case

Those names hide the outcome or the behavior that matters.

Common abbreviations used in test names

Entity Common abbreviation
Activation Key ak
Content View cv
Content View Filter cvf
Content View Version cvv
Lifecycle Environment lce
Organization org
Repository repo
Content Host chost

Use abbreviations sparingly. If the expanded form is clearer, prefer the full name.

Pattern ideas from existing conventions

Common naming fragments that read well in Robottelo:

  • create_with_<value>
  • update_<field>
  • delete_by_<selector>
  • add_<association>
  • remove_<association>
  • search_by_<field>
  • promote_with_<condition>

These are guidelines, not a rigid grammar. Clarity matters more than forcing a template that reads awkwardly.

Docstring metadata still matters

The function name is only part of the test identity. Functional tests should also include the required testimony-style docstring metadata, especially :id:, :steps:, and :expectedresults:.

FAQ

Should I rename a test just because I refactored the implementation?

Usually no. Rename it when the intent, expected behavior, or coverage focus changed, not just because the internals changed.

When is an abbreviation acceptable?

When it is already common and readable in the repo, such as ak, cv, repo, or lce. If the abbreviation makes the test harder to scan, spell it out.

⚠️ **GitHub.com Fallback** ⚠️