Vividus Framework Documentation

VIVIDUS is a test automation tool designed for test engineers to automate testing across various application types (UI, API, DB) using a single tool and a common language. It is built to be accessible to users without deep programming skills while providing powerful integration points for CI/CD systems.

Key features include:

• Test Actions Language: A human-readable, Gherkin-formatted language used to write executable tests. Unlike classical BDD, it is not limited to a specific domain.
• All-in-one testing: Combines multiple testing tool capabilities into a single application.
• Ready-to-use: Includes an implemented dictionary of Test Actions, embedded user documentation, and a Test Report module.
• Open Source: Distributed under the Apache License 2.0.

The Visual Testing Plugin allows you to perform visual regression testing by establishing baselines and comparing current screenshots against them. It supports both Web and Mobile Native applications and provides various shooting strategies to capture screenshots.

Core Actions:

• ESTABLISH: Creates a new baseline image.
• COMPARE_AGAINST: Compares the current screenshot with an existing baseline.
• CHECK_INEQUALITY_AGAINST: Checks if the difference between the current screenshot and baseline exceeds a specific threshold.

VIVIDUS uses the Test Actions Language to write executable tests. This language is designed to be human-readable and follows the Gherkin format, making it accessible to testers of various technical levels.

Unlike traditional Behavior Driven Development (BDD) which is often tied to specific business domains, the Test Actions Language in VIVIDUS is generic and can be applied to any application or domain (e.g., UI elements, API datasets, or Database objects).

Profiles allow you to define environment-specific or device-specific properties (e.g., browser type, mobile device settings).

• Set the profile path using configuration.profiles in configuration.properties.
• Profiles are loaded sequentially from last to first, allowing you to define common properties in a base profile and specific properties in nested sub-profiles.
• Note: VIVIDUS does not support running multiple profiles simultaneously; it merges the properties of the selected profile sequence.

Example Directory Structure:

src/main/resources/properties
  └─ profile
      ├─ web
      │   ├─ chrome
      │   │   └─ profile.properties
      │   └─ profile.properties
      └─ profile.properties

# Point to a specific nested profile
configuration.profiles=mobile_app/android

The JSON plugin provides two additional functions for use within JSON path expressions:

1. distinct(): Removes duplicated items from the input array.

   • Example: $.type.distinct() on ["b", "b", "a"] returns ["b", "a"].

2. random():

   • random(): Returns a single random element from the input array.
   • random(n): Returns an array of n random elements from the input array.
   • Note: Results vary on each execution.

Example of random(n):

{
    "numbers": [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
}

Path: $.numbers.random(3) Result: [4, 7, 2] (example output)

$.type.distinct()
$.colors.random()
$.numbers.random(3)

When performing resource validation, the system follows a specific fallback mechanism using HTTP methods to determine if a resource is valid.

1. Initial Check: The system executes a HEAD request for each received value.
2. Success Condition: If the HEAD request returns a 200 OK status code, the resource validation is considered passed.
3. Fallback Mechanism: If the HEAD request returns any of the following status codes:
   • 404 Not Found
   • 405 Method Not Allowed
   • 501 Not Implemented
   • 503 Service Unavailable the system will then execute a GET request.
4. Final Validation: After the fallback GET request:
   • If the status code is 200 OK, the validation is considered passed.
   • Otherwise, the validation is considered failed.

VIVIDUS uses a deprecation mechanism that allows the framework to:

1. Log a warning when a deprecated property is used.
2. Treat the deprecated property as if it were the actual (new) property.
3. Automatically replace the deprecated key with the new key using the replaceDeprecatedProperties command.

For developers creating modules, deprecations are defined in <module-name>/src/main/resources/properties/deprecated/deprecated.properties using the format <deprecated property>=<actual property>.