Versions Compared

Old Version 2

changes.mady.by.user Karl Henselin

Saved on

compared with

New Version 3

changes.mady.by.user Chandresh Patel

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Test Automation provides a way for you to define tests. These are often used as smoke tests to ensure that the deployment completed successfully. They can also be used to run regression tests and any other testing that is targeted to the deployed target. Tests can be executed as part of build, deploy or utility workflow executions as well.

The Test Automation configurations, defined in YAML, are found in the project configuration.

...

The YAML that is shown here can also be stored in source control in the projet_root/fdtests folder to allow for versioning of the test configuration. For example:

...

Info

  • Once YAML file is stored in source control you can safely delete the test automation configuration from your project. If you inactivate test automation configuration on project, it will not be used.

  • It would be better to use project configuration or source control to avoid confusion. If both configuration files are used then they will be combined such that project configuration will override source control file for same testName. We recommend using project configuration as it would be much easier to manage.

  • If you inactivate test automation configuration on project, it will not be used.

  • Files stored in project_root/fdtests are discovered and automatically saved to artifacts directory on build execution. This applies to Package-based projects as well.

  • Changes in project_root/fdtests folder does not trigger CI build for Package-based projects as these files are not considered part of Package.

...

Open the project you would like to add automated testing to and click Get Started.

...

A guide to getting started will be shown, similar to the following:

...

Armed with this information, type test- and select a tool you want to use for running tests.

...

While modifying the test configuration in the editor, available fields and values will always be suggested to you. As such understanding the YAML definition below is certainly NOT REQUIRED but certainly can be helpful in understanding how things work.

Field

Data type

Description

Notes

[testRoot] denoted ---

Array

Multiple tests can be defined in the YAML configuration and are separated by ---

Every test in the file must start with --- specified on its own line

testName

String

Unique name of the test within the YAML configuration

When executing tests you can specify a specific name filter to execute individual tests

description

String

Description of the test

-

workflow

Object

The workflow that will be executed when executing this test

workflow/name

String

The name of the workflow as it appears in the workflow UI

Valid test workflow names show as editor suggestions. Can be triggered by typing or hitting ctrl+space while on the name field

workflow/inputs

Array

A list of workflow inputs for the specified workflow. Only inputs configured on the workflow are valid here

All available inputs for the specified workflow will be auto inserted when auto completing the inputs field, provided the name has already been specified

workflow/inputs/code

String

Workflow Input Code for the specified workflow. It should match the code as seen on the workflow screen

Valid workflow input codes will be suggested provided the workflow name has been specified

workflow/inputs/value

String

The value of the current workflow input

Can be plain text or variables can be used.

workflow/inputs/groovy

Boolean

Flag indicating if the provided value should be treated as a groovy expression

tags

String

@Since 7.0.0.1 - A comma separated list of tags used for filtering tests on execution

Quick selection of tags can be accessed by hitting ctrl+space. This will display a list of tags already in used within the YAML

filters

Array

A list of filters that limit the conditions under which the given test will execute

For example an env filter with a value of DEVELOPMENT will ensure this test is only run when executing in the DEVELOPMENT environment

filters/type

String

The type of filter to use. Valid values are: branch, env, file, pkg, targetGroup

filters/value

String

The value of the supplied filter

Possible values are suggested based on the filter/type specified

Integrating with Release/Pipeline

...

  • Executes any tests on projects in the Development Environment after deployment to the Development Environment. This means any tests with an env filter with a value of DEVELOPMENT or no filters at all would be executed as seen below.

    • If using Package-based project, only unique Tests (by Test Name) will be executed when multiple Packages from same Project are included in Release.

Code Block
---
testName: Postman Test
description: Generated Postman Test
filters: 
  - type: env
    value: DEVELOPMENT
workflow:
  name: PostmanDocker
  inputs: 
    - code: FDPMN_COLLECTION_FILE
      value: .*collection.json
     # (Optional) null
    - code: FDPMN_ENVIRONMENT_FILE
      value: fdtests/postman_environment_TOMCATPOSTGRES.json

...

Then, add it to your workflow inputs and map it to your endpoint selection override. It controls where the test will be run.

...

image-20241008-205146.pngImage Added