Concordia Compiler uses plug-ins for:

1. setting the testing environment up;

2. generating and executing test scripts;

3. converting and reporting test results.

Every plug-in can generate test scripts for a different testing framework or programming language.

Plug-ins

Notes:

• (*) RTS means "Requires a Testing Server", that is, if it requires a testing server to run the test scripts (e.g., Selenium Standalone).

• (**) Appium requires Java for testing web-based mobile applications or using the Android SDK.

• codeceptjs-testcafe uses the frameworks CodeceptJS and TestCafé, and works with probably any browser.

• codeceptjs-playwright uses the frameworks CodeceptJS and Playwright,

  requires Node 10.14 or above, and works with Chromium, Firefox, and Safari.

• codeceptjs-webdriverio uses the frameworks CodeceptJS and WebDriverIO, and works with Chrome, Firefox, IE, and Edge.

• codeceptjs-appium uses the frameworks CodeceptJS and Appium, and requires some additional configuration to work.

• codeceptjs-testcafe and codeceptjs-playwright are only available for Concordia Compiler 2 or above.

Installation

Use --plugin-install plus the plug-in name. Example:

npx concordia --plugin-install codeceptjs-testcafe

Upgrade

Just uninstall the plug-in and then install it again. Example:

npx concordia --plugin-uninstall codeceptjs-playwright
npx concordia --plugin-install codeceptjs-playwright 

How to use a plug-in

Concordia has the following plug-in commands:

• plugin-install to install a plug-in

• plugin-uninstallto uninstall a plug-in

• plugin-serve to start a testing server using the plug-in

• plugin to use a plug-in

• plugin-info to show information about a plug-in

• plugin-list to list installed plug-ins

All but the latter command (plugin-list) require a plug-in name.

👉 Whether you have a configuration file with the property plugin defined, you can omit the plugin name from a command. Example:

{
  "plugin": "codeceptjs-playwright"
}

Commonly used commands

Starting a testing server

Some plug-ins (WebDriverIO, Appium) require a testing server to execute test scripts. A testing server controls a browser or an emulator during tests.

We recommend to open a new terminal/console and then start the testing server:

npx concordia --plugin-serve <plugin>

The testing server will remain open. To stop it later, type Ctrl + C.

Generating and executing test scripts

npx concordia --plugin <plugin>

Generating test scripts without executing them

You can use --no-run to avoid running test scripts and use --no-result to avoid reading the last report with test results. Test scripts will be generated but not executed.

npx concordia --plugin <plugin> --no-run --no-result

Executing existing test scripts (without generating them)

You can use --no-script to avoid generating test scripts. Only existing test scripts will be executed.

npx concordia --plugin <plugin> --no-script

See also

• Configuration file

• Commands for plug-ins

• Creating a plug-in

Welcome to the Concordia 2 documentation! This page will help you to get started fast. If you run into problems, you can find help on our Slack channel.

System Requirements

Concordia Compiler requires only NodeJS version 12.20 (or above) and works on Linux, MacOS and Windows.

In this Quick Start, we'll create a simple specification of an interaction with a search page and use Google Chrome. Therefore, download it before continuing.

Step 0: Initialize

If you are starting a new project or whether your project does not have a file named package.json, then run:

npm init --yes

Step 1: Install

Install Concordia Compiler locally:

npm i -D concordialang

Step 2: Configure

npx concordia --init

Concordia Compiler will ask you about some preferences. Press Enter to answer every question with their default values. It will create a configuration file named .concordiarc and install the selected plug-in and database drivers.

Step 3: Create a feature

Create the folderfeatures :

mkdir features

Now create the file search.feature withinfeatures, with the following content:

Feature: Search

Scenario: Shows results that correspond to the term

  Variant: Search by pressing Enter
    Given that I am on "https://google.com"
    When I type "concordialang" in <q>
      And I press "Enter"
      And I wait for 2 seconds
    Then I see "npm"

About the file:

• Feature and Scenario are high-level, business-focused descriptions about the problem to solve. Their sentences are not used to generate test cases. The above example does not describe them.

• A Variant describes the expected interaction with the application's user interface (UI) in order to perform a Scenario. Thus, a Variant uses technological vocabulary.

• In Concordia, all the interactions with the UI use first person singular ("I"). That "I" represents the actor that is interacting with the application (in the example above, a visitor).

Step 4: Execute

Finally, run

npx concordia

It will:

• set the testing environment up (once);

• generate a test case file and transformed it into a test script file;

• execute the test script file; and

• report the test script results.

Your browser should open automatically during this process and the console will report the execution results.

Your directory should now look like this:

 ┃
 ┣ features/          
 ┃ ┣ search.feature
 ┃ ┗ search.testcase     🡐 generated test case
 ┣ node_modules/
 ┣ test/              
 ┃ ┗ search.js           🡐 generated test script
 ┣ .concordiarc
 ┣ codecept.json
 ┣ package.json  
 ┗ package-lock.json

The directory node_modules contains installed dependencies, like tools and frameworks, whose versions are managed with package.json and package-lock.json. The file codecept.json has a basic configuration to run CodeceptJS with Google Chrome and you can change it to fit your needs.

The file features/search.testcase should look like this:

# Generated with ❤ by Concordia
#
# THIS IS A GENERATED FILE - MODIFICATIONS CAN BE LOST !

import "search.feature"

@generated
@scenario(1)
@variant(1)
Test Case: Search by pressing Enter - 1
  Given that I am on "https://google.com"
  When I type "concordialang.org" in <q>
    And I press "Enter"
    And I wait for 2 seconds
  Then I see "npm"

The Test Case above was produced from the Variant declared in features/search.feature. Some notes about it:

• The import clause (line 5) imports the declared file's content.

• The tag @generated (line 7) indicates that the Test Case was produced automatically.

• The tag @scenario(1) (line 8) indicates that the Test Case belongs to the first Scenario (1).

• The tag @variant(1) (line 9) indicates that the Test Case belongs to the first Variant (1) of the Scenario declared previously.

• The Test Case (line 10) is named using the Variant's name plus dash (-) and some (incremental) number. Its content is basically the same as the Variant's, since we did not use any other declarations.

The file test/search.js contains the test script produced from features/search.testcase using the selected plug-in. It also contains line comments with references to their corresponding lines and columns in the .testcase file:

// Generated with ❤ by Concordia
// source: search.testcase
//
// THIS IS A GENERATED FILE - MODIFICATIONS CAN BE LOST !

Feature("Search");

Scenario("Shows results that correspond to the term | Search by pressing Enter - 1", (I) => {
    I.amOnPage("https://google.com"); // (11,2)
    I.fillField("q", "concordialang.org"); // (12,2)
    I.pressKey("Enter"); // (13,4)
    I.wait(2); // (14,4)
    I.see("npm"); // (15,2)
});

Notes on installation options

You can opt to install Concordia Compiler locally (per project) or globally.

Local installation (recommended)

• does not require administrative privileges (i.e., using sudo on Linux or MacOS) to install;

• allows every project to have its own, independent installation;

• demands using NPX before every command.

Follow the Quick Start for a install installation.

Global installation

• requires administrative privilegies (i.e., using sudo on Linux or MacOS) to install;

• lets you execute the compiler direcly from any folder;

• needs more attention when upgrading, especially for plug-ins.

Example:

sudo npm install -g concordialang
concordia --version

Note: On Windows, you must omit sudo.

Additional tips:

• How to install globally with NPM on Linux or MacOS without sudo.

• Whether Windows requires administrative privileges to install, right click Windows (Start) menu, click "Command Prompt (Admin)" or alternatively "Windows PowerShell (Admin)", and then proceed with the installation command.

• To upgrade Concordia later, change the installation command from install to upgrade.

Concordia can use databases to retrieve test data or to set the testing environment up before or after running test scripts.

Installation

Installing

Use --db-install plus the driver name. Example:

npx concordia --db-install mysql

Available driver names:

Database drivers are installed as development dependencies of your application.

Uninstalling

Use --db-uninstall plus the driver name. Example:

npx concordia --db-uninstall mysql

Upgrading

Just uninstall and then install it again.

Usage

A Database is global declaration. You must declare it once and then import its file in other features. Example:

Database: My DB
  - type is "mysql"
  - host is "127.0.0.1"
  - name is "acme"
  - username is "tester"
  - password is "secret"
  
Database: Another DB
  - type is "json"
  - path is "./db.json"

A database can be referenced inside UI properties and Test Events by its name between [ and ]. Example: [My DB]. To reference a database table, separate the table name from the database name with with a dot (.) - e.g. [My DB.profession]. Let's see an example:

import "db.feature"

# ... other declarations here ...

UI Element: Profession
  - value comes from "SELECT name FROM [My DB.profession]"
    Otherwise, I see "Profession not found."
  - required
    Otherwise, I see "Please select the profession."
    
Before Each Scenario:
  Given that I connect to [My DB]
  When I run the script 'DELETE FROM profession'
    and I run the script 'INSERT INTO profession (name) VALUES ("Enginner"), ("Accountant")' 
    

Instead of reinventing the wheel, Concordia uses SQL to query and modify databases and files. Even JSON and INI files can be queried with SQL.

In the example above, the property value from the UI Element "Profession" indicates that its (valid) values are retrieved from the table "profession" that belongs to the database declared as "My DB". The test event Before Each Scenario was declared to connect to the database, clean the table "profession", and then insert new records that the UI Element "Profession" will use.

See also

• Supported syntax

• Declaring Tables

Imagine a solution in which you can write software requirements using an Agile-style, restricted natural language and it automatically generates functional test scripts for you using effective testing techniques such as equivalence partitioning, boundary-value analysis, random testing and combinatorial testing and it can also use test data from databases and files. Well, that's Concordia. Its solution is composed by a metalanguage and a compiler.

Concordia metalanguage

Concordia metalanguage allows you to focus on writing your application's business rules and defining its expected behavior for when users interact with it. Stakeholders, business analysts, testers, and programmers can now discuss the application using a single language, a single source of truth. Business-focused and testing-focused declarations are clearly separated, so you can discuss technological details only with the interested parties.

With Concordia, you can write both functional and non-functional requirements, although it produces only functional test cases. Because it adopts Agile-style declarations, you don't have to write it so formally (like Use Cases usually do) and you can use plain text - which is easy to evolve with your codebase.

We invite you to take a look at the language and see how it is easy to understand. It is currently available in English (en) and Portuguese (pt).

Concordia compiler

Concordia compiler mix compiler techniques with machine learning and natural language processing to understand declarations in Concordia Language - which uses restricted natural language. After detecting declarations, it infers test scenarios, test data, and test oracles to generate test cases in a framework-independent format (see the produced test cases). Finally, it uses a plug-in created for a specific testing framework to generate test scripts (that is, source code), execute them and read their results. You don't need to write code. And the compiler checks your declarations for logic errors and other possible problems.

Follow the Quick Start to see it in action! 😉

Concordia plug-ins

Concordia compiler uses plug-ins to transform Abstract Test Cases (ATS) into test scripts - that is, into source code. Every plug-in can be implemented to generate source code for a specific programming language and testing framework - in Java, Python, Go, PHP or whatever the language you prefer. The generated source code is not tied to JavaScript or TypeScript.

See the available plug-ins and how to create a plug-in for your favorite programming language and testing framework.

Overview of the Concordia declarations:

Features and Scenarios

A Featuredefines a desired behavior for the software, a piece of functionality that gives some business value. A Scenario is a high-level usage scenario of a Feature. A Feature can have many Scenarios.

Since Feature and Scenario are business-oriented declarations, they are not used by Concordia Compiler to generate test cases. You can write them freely. Although, we recommend you to use the User Story template for a Feature and the Given-When-Then template for a Scenario. Example:

Feature: Sales Report
  As a manager
  I would like to generate a sales report
  In order to track company sales

Scenario: Daily sales report
  Given that I am authenticated as a manager
  When I open the sales report
    and I choose the option "Daily report"
  Then I see a list with all the today's sales 
    and the total value

This is the User Story template:

• As a <role>

• I would like to <goal to perform>

• In order to <received benefit> (or So that <received benefit>)

And this is the Given-When-Then (GWT) template:

• Given <some context or precondition>

• When <some action is carried out>

• Then <a result or postcondition is observed>

In the GWT template, additional sentences of each kind are written in the next line and receive the prefix and.

Features and Scenarios must have a name, but their description are not required. Thus, you can write the above example like this (although we recommend against):

Feature: Sales Report

Scenario: Daily sales report

Feature files receive the extension .feature. Only one feature per file is allowed.

Variants

A Variant is a test-oriented declaration that describes a possible interaction between a user and the system in order to accomplish a Scenario. You can write more than one Variantfor a same Scenario .

A Variant must use the GWT template and first person singular ("I") in its sentences. Concordia Compiler uses Natural Language Processing (NLP) techniques to understand Variant sentences, aiming to transform them into test cases. Example:

Feature: New User

Scenario: Successful registration

  Variant: Register with a new account
    Given that I am on "https://example.com/register"
    When I fill <#name> with "Bob"
      and I fill <#dateOfBirth> with "11/30/1990"
      and I enter with "bob@example.com" in <#email>
      and I inform "m123456" in <#pass>    
      and I type "m123456" in <#confirmation>
      and I click <#ok>
    Then I see "Welcome, Bob" 

Concordia Compiler understands the sentences from line 7 to11 as being variations of the same action, fill.

Of course, the vocabulary is limited. Although, you can extend it whether you need (by adding new synonyms to a specific dictionary file). Actions and common variations are documented and suggestions are always welcomed.

In the sentences above, the values were denoted between quotation marks, e.g. "bob@example.com". Numeric values are also accepted and do not need quotation marks. Example: 97.

Widgets (of the user interface) are written between < and >. Example: <#email>. Concordia adopts the well-known CSS query selectors to locate widgets, regardless the user interface (its plugins convert them to the format adopted by the testing framework). You can also use XPath (although some plug-ins may not accept it). Examples:

• # (hashtag) to find a widget by its id. Example: #email

• . (dot) to find a widget by its class, if applicable. Example: .colorful

• @ (at) to find a widget by its name. Example: @pass

• ~ (tilde) to find a widget by its mobile name, if applicable. Example: ~pass

• no prefixed characters, to find a widget by its type. Example: input

• // (double slash) to find a widget by its XPath. Example: //table/tbody/tr[1]

States

A State is denoted by a text between tilde (~), such as ~a state~, and must be written inside Variant sentences only. Example:

Then I have a ~user logged in~

A Variant can both produce or require states. A State is produced by a Then sentence, like in the prior example. A State is required by a Given or a When sentence. For instance:

Given that I have ~user logged in~

By declaring a required State, you're establishing a dependency among the current Variant and the ones that can produce it. Since that State is often produced by a Variant from another Feature, you have to import the corresponding Feature file. Concordia Compiler will only search for states from imported Feature files.

When transforming Variants into Test Cases, Concordia Compiler will:

• Remove any (Then) sentences with a produced State; and

• Replace any (Given or When) sentences with a required State by sentences from the Variant that can produce it.

Whether there are different Variants that can produce a (same) required State, Concordia Compiler will be able to combine each of them with the current Variant, aiming to produce Test Cases that explore different execution paths. For more information, please read the section State Based-Combination.

Example

Let's say that we have a simple Login feature like this:

Feature: Login

Scenario: Sucessful login

  Variant: Login with username and password
    Given that I am on the [Login Screen]
    When I enter with "bob" in {Username}
      and I enter with "123456" in {Password}
      and I click on {OK}
    Then I see "Welcome"
      and I have ~user logged in~


Constants:
  - "Login Screen" is "/page"
  
UI Element: Username

UI Element: Password

UI Element: OK
  - type is button

Now let's suppose that a user has to be logged in to access its account details:

import "login.feature"

Feature: My Account

  Scenario: See my account data
  
    Variant: Show basic data by default
      Given that I have ~user logged in~
        and I am on the [Account Screen]
      Then I see {User} with "bob"
        and I see {Name} with "Robert Downey Jr"


Constants:
  - "Account Screen" is "/account"
        
UI Element: User

Concordia Compiler will produce my-account.testcase with a Test Case like the following, that includes steps from both the features:

import "my-account.feature"

@scenario(1)
@variant(1)
Test Case: See my account data - 1
  Given that I am on the "/login"
  When I enter with "bob" in <username>
    and I enter with "123456" in <password>
    and I click on <ok>
  Then I see "Welcome"
  Given that I am on the "/account
  Then I see <user> with "bob"
    and I see <name> with "Robert Downey Jr"

Test Cases

A Test Case represents a test case produced for a certain Variant . Concordia Compiler can generate many Test Case declarations from a same Variant, each one covering different states, input combinations and oracles. The generation considers the following declarations:

• Variant

• states

• UI Element

• Constants

• Table

• Database

The simplest Test Case is one whose sentences are exactly equal to the Variant's. That's the case when the Variant does not use other declarations and it explicits all the input test data to use.

For comparison, whether we simply remove with "Bob"from the sentenceWhen I fill <#name> with "Bob" , Concordia Compiler will generate a pseudo-random value to complete the sentence, and it will be like this: When I fill <#name> with "A~!39esljdns so2u1 *ns%".

Concordia Compiler uses a single seed to generate pseudo-random numbers in its algorithms and values. Everytime it runs, a new seed is produced. You can set the seed using the CLI parameter --seed. By setting the seed, the compiler will pick the same paths and produce the same values - which is desirable for reproducing the same behavior in the application under test, but not for discovering new defects.

UI Elements

A UI Element represents a user interface element and can denote its expected behavior through properties.

Although a Widget is easy to declare, it can have some shortcomings:

1) It can make a sentence hard to read, specially when it uses XPath or CSS locators.

When I click on <//*[@id="section1"]/div[1]/div[2]>

When I click on {Continue}

UI Element: Continue
  - locator: //*[@id="section1"]/div[1]/div[2]  

2. It can be hard to maintain. When a Widget appears in more than one Scenario and its locator needs to change (e.g. you have changed it in the UI), you need to search and replace all its occurrences in the document. With a UI Element, you just need to change the property locator.

3. It does not offer resources for test generation other than its locator.

A UI Element offers properties that can describe the behavior related to it. These properties are used to infer the test data and test oracles to generate.

Example:

UI Element: Net Price
  - minimum value is 10.00
    Otherwise I see "Net Price must be greater than U$ 10"    

These are the UI Element properties:

• id or locator ⇨ how to locate the widget

• type ⇨ widget type, like textbox, button, etc.

• editable ⇨ whether the UI Element is editable (or not)

• data type ⇨ data type of an editable UI Element

• required⇨ whether the UI Element is required (or not)

• format⇨ data format, denoted by a regular expression

• value⇨ defines how the value is produced

• minimum value ⇨ defines how the minimum value is produced

• maximum value ⇨ defines how the maximum value is produced

• minimum length ⇨ defines how the minimum length is produced

• maximum length ⇨ defines how the maximum length is produced

By default, declaring a UI Element without properties is the same as declaring it with:

• id or locator equal to the UI Element name in camelCase (e.g., "Net Price" becomes "netPrice"). The adopted case is configurable.

• type equal to textbox

• data type equal to string

Another example:

UI Element: Profession
  - value is in [ "Programmer", "Tester", "Analyst" ]

Please see the language reference for more details. Let's proceed with the other declarations for now.

Import

A Import declaration allows you to import declarations from another .featurefile. Example:

Import "login.feature"

Imported declarations are Feature, Constants, Table, Database, and UI Element.

Constants

A Constants block defines one or more constants. Every Constant holds an immutable value that is accessible through the declared name. Example:

Constants:
  - "Register Page" is "https://example.com/register"
  - "Coupon Number" is 12345

Constants are accessed by their name between [ and ]. Example:

    Given that I am on the [Register Page]
    When I fill {Coupon} with [Coupon Number]

Constants are global declarations and cannot have duplicate names. You can use them in UI Element properties and Variant sentences.

Table

A Table declares values in rows and columns to use in UI Element properties. Example:

Table: Customer
  | name           | age |
  | Ada Lovelace   | 36  |
  | Dennis Ritchie | 70  |
  | Donald Knuth   | 82  |
  | George Boole   | 49  |
  | Niklaus Wirth  | 83  |
  
  
UI Element: Name
  - value comes from "SELECT name FROM [Customer]"
    Otherwise I see "Customer not found."

Note that SQL is used to select values from the declared table, which is denoted between [ and ] (like Constants). Table names are global and share the same namespace as Constant names.

Database

A Database provides a way to indicate a connection to an existing database or file. Example:

Database: AcmeDB
  - type is "mysql"
  - name is "acme"
  - host is "http://127.0.0.1"
  - username is "tester"
  - password is "testing123"
  
  UI Element: Name
  - value comes from "SELECT name FROM [AcmeDB.customer]"
    Otherwise I see "Customer not found."

SQL is used to select values from a table or view from the declared database, which is denoted between [ and ] . Its table or view names are separated by a dot (.). Database names are global and share the same namespace as Tables and Constants.

Test Events

In order to set the execution environment up, testers can define events that can run database commands or command-line scripts. These events can occur before or after Scenarios or Features:

• Before Each Scenario: executes before every test of each Scenario of the current Feature.

• After Each Scenario: executes after every test of each Scenario of the current Feature.

• Before Feature: executes once, before all the tests of the current Feature.

• After Feature: executes once, after all the tests of the current Feature.

• Before All: executes once, before all the tests of the application under test.

• After All: executes once, after all the tests of the application under test.

Test Events are written like Variants, using Given-When-Then. Since they usually perform actions, it is very likely to useWhen in most sentences. Example:

Before Feature:
   Given that I connect to [AcmeDB]
   When I run the script 'DELETE FROM customer'
     and I run the script 'INSERT INTO customer ( name, age ) VALUES ( "Alice", 20 ), ( "Bob", 30 )'     
     and I run the command 'rmdir log'

Commands and database scripts are denoted between apostrophe (').

Let's suppose that we have to create two simple features for a web application: "Login" and "Add Product". After discussing them with stakeholders and the team, we created the following Concordia specification (see the two tabs):

Feature: Login
  As a user
  I would like to authenticate myself
  In order to access the application

Scenario: Successful login
  Given that I can see the login screen
  When I enter with valid credentials
  Then I can access the application's main screen
  
  Variant: Login with username and password
    Given that I visit the [Login Screen]
    When I fill {Username}
      And I fill {Password}
      And I click on {OK}
    Then I see "Welcome"
      And I have a ~user logged in~

Table: Users
  | username | password  |
  | bob      | 123456    |
  | alice    | 4l1c3pass |

UI Element: Username
  - required
    Otherwise I must see "Please inform the username."
  - value comes from "SELECT username FROM [Users]"
    Otherwise I must see "Invalid username."    

UI Element: Password
  - required
    Otherwise I must see "Please inform the password."
  - value comes from "SELECT password FROM [Users] WHERE username = {Username}"
    Otherwise I must see "Invalid password."

UI Element: OK
  - type is button
  
Constants:
  - "Login Screen" is "/login"  
  

import "login.feature"

Feature: Add Product
  As an employee
  I would like to add a product
  In order to manage its data and sale it
  
Scenario: Add a new product with basic data
  Given that I am logged in
  When I add a product with SKU, description, department, price, and quantity
  Then I am able to register it
  
  Variant: Basic data
    Given that I have a ~user logged in~
      and I visit the [Product Screen]
    When I fill {SKU}
      and I fill {Description}
      and I fill {Price}
      and I fill {Quantity}
      and I click on {Save}
    Then I have ~product registered~
      and I see "Saved."

UI Element: SKU
 - required
   Otherwise I see "Please inform the SKU."
 - format is "/[A-Z]{3}\-[0-9]{3}/"
   Otherwise I see "Invalid SKU format. Please use 3 letters, dash, 3 numbers." 
    
UI Element: Description
  - minimum length is 2
    Otherwise I see "Description needs at least 2 characters."
  - maximum length is 100
    Otherwise I see "Description must have at most 100 characters."    
    
UI Element: Price
  - required 
    Otherwise I see "Please inform the price."  
  - minimum value is 0.01
    Otherwise I see "Minimum price is one cent."
    
UI Element: Quantity
  - data type is integer

UI Element: Save
  - type is button    

Constants:
  "Product Screen" is "/products/new"

These features could correspond to the following sketches:

The specification helps stakeholders, analysis, testers and developers to create a shared understanding about the application and its business rules. It helps with the requirements validation, knowledge documentation, project design, implementation and testing.

Different from Use Cases and other requirements specification formats, with Concordia you probably don't need to define different scenarios for validation. Instead of having to manually define a set scenarios for validation, you just need to define how the UI elements should behavior - in their declaration - and the compiler will generate different scenarios for you in the form of Test Cases. Whether your application has a lot of such rules, your team will certainly benefit from it.

<TO-DO (UNDER CONSTRUCTION)>

Remember that a Variant express a possible interaction between a user and the application in order to complete its (business-focused) Scenario. lt follows the GWT syntax and always uses the word "I" to represent the user or user role denoted in the Feature's description.

Let's run Concordia Compiler with a seed to produce the same results over and over again:

npx concordia --seed="example" --no-run --no-result

It will generate login.testcase with the following content:

<TO-DO (UNDER CONSTRUCTION)>

<TO-DO (UNDER CONSTRUCTION)>

If a seed is not given, Concordia Compiler assumes the current date and time. The seed is always printed in the console so that you or your team can reproduce the same paths, test data, and test oracle that were able to expose a bug in your application. Here we are giving it for a sake of reproduction.

Using the same seed over and over again will make Concordia Compiler produce the same results. Options no-run and no-result avoid running the test scripts and getting execution results.

Execution without generation

This will not generate test cases or test scripts, but it will execute them and get their results:

$ concordia --plugin=codeceptjs --no-test-case --no-script

Output

login.testcase:

# Generated with ❤ by Concordia
#
# THIS IS A GENERATED FILE - MODIFICATIONS CAN BE LOST !

import "login-en.feature"

@generated
@scenario(1)
@variant(1)
Test case: Successful login with valid credentials - 1
  Given that I am in the "http://localhost/login"  # [Login Screen]
  When i fill <username> with "*RM)O,"  # invalid: inexistent element
    And i fill <password> with ""  # valid: last element
    And I click on <ok>  # {OK}
  Then I must see "Invalid username"  # from <username>

@generated
@scenario(1)
@variant(1)
Test case: Successful login with valid credentials - 2
  Given that I am in the "http://localhost/login"  # [Login Screen]
  When i fill <username> with "bob"  # valid: filled
    And i fill <password> with -8655972838932479  # invalid: inexistent element
    And I click on <ok>  # {OK}
  Then I must see "Invalid password"  # from <password>

@generated
@scenario(1)
@variant(1)
Test case: Successful login with valid credentials - 3
  Given that I am in the "http://localhost/login"  # [Login Screen]
  When i fill <username> with "alice"  # valid: random element
    And i fill <password> with "4l1c3pass"  # valid: random element
    And I click on <ok>  # {OK}
  Then I see "Welcome"

@generated
@scenario(1)
@variant(1)
Test case: Successful login with valid credentials - 4
  Given that I am in the "http://localhost/login"  # [Login Screen]
  When i fill <username> with "alice"  # valid: last element
    And i fill <password> with "4l1c3pass"  # valid: filled
    And I click on <ok>  # {OK}
  Then I see "Welcome"

@generated
@fail
@scenario(1)
@variant(1)
Test case: Successful login with valid credentials - 5
  Given that I am in the "http://localhost/login"  # [Login Screen]
  When i fill <username> with ""  # invalid: not filled
    And i fill <password> with ""  # invalid: not filled
    And I click on <ok>  # {OK}
  Then I see "Welcome"

@generated
@scenario(1)
@variant(1)
Test case: Successful login with valid credentials - 6
  Given that I am in the "http://localhost/login"  # [Login Screen]
  When i fill <username> with "bob"  # valid: first element
    And i fill <password> with 123456  # valid: first element
    And I click on <ok>  # {OK}
  Then I see "Welcome"

test/login.js:

// Generated with ❤ by Concordia
// source: c:\code\tmp\concordia-test-pt\login-en.testcase
//
// THIS IS A GENERATED FILE - MODIFICATIONS CAN BE LOST !

Feature("Login");

Scenario("Successful login | Successful login with valid credentials - 1", (I) => {
    I.amOnPage("http://localhost/login"); // (61,5)  [Login Screen]
    I.fillField("username", "*RMO,"); // (11,5)  invalid: inexistent element
    I.fillField("password", ""); // (12,7)  valid: last element
    I.click("ok"); // (64,7)  {OK}
    I.see("Invalid username"); // (14,5)  from <username>
});

Scenario("Successful login | Successful login with valid credentials - 2", (I) => {
    I.amOnPage("http://localhost/login"); // (61,5)  [Login Screen]
    I.fillField("username", "bob"); // (21,5)  valid: filled
    I.fillField("password", "-8655972838932479"); // (22,7)  invalid: inexistent element
    I.click("ok"); // (64,7)  {OK}
    I.see("Invalid password"); // (24,5)  from <password>
});

Scenario("Successful login | Successful login with valid credentials - 3", (I) => {
    I.amOnPage("http://localhost/login"); // (61,5)  [Login Screen]
    I.fillField("username", "alice"); // (31,5)  valid: random element
    I.fillField("password", "4l1c3pass"); // (32,7)  valid: random element
    I.click("ok"); // (64,7)  {OK}
    I.see("Welcome"); // (65,5)
});

Scenario("Successful login | Successful login with valid credentials - 4", (I) => {
    I.amOnPage("http://localhost/login"); // (61,5)  [Login Screen]
    I.fillField("username", "alice"); // (41,5)  valid: last element
    I.fillField("password", "4l1c3pass"); // (42,7)  valid: filled
    I.click("ok"); // (64,7)  {OK}
    I.see("Welcome"); // (65,5)
});

Scenario("Successful login | Successful login with valid credentials - 5", (I) => {
    I.amOnPage("http://localhost/login"); // (61,5)  [Login Screen]
    I.fillField("username", ""); // (52,5)  invalid: not filled
    I.fillField("password", ""); // (53,7)  invalid: not filled
    I.click("ok"); // (64,7)  {OK}
    I.see("Welcome"); // (65,5)
});

Scenario("Successful login | Successful login with valid credentials - 6", (I) => {
    I.amOnPage("http://localhost/login"); // (61,5)  [Login Screen]
    I.fillField("username", "bob"); // (62,5)  valid: first element
    I.fillField("password", "123456"); // (63,7)  valid: first element
    I.click("ok"); // (64,7)  {OK}
    I.see("Welcome"); // (65,5)
});

3. Analyze the results

Whether you ran the test scripts above, you probably saw they fail. That's because they didn't find a web application running at http://localhost/login or because the application was found but it did not match the expected behavior. You may adapt your application and run the tests again.

Concordia shows a report that indicates the failures' locations. They help you to decide if a failure was caused by the application under test (e.g., it did not behave as expected) or because of the requirements specification (e.g., it is outdated in relation to the application).

Now keeping your specification updated has a new clear benefit: you can use it to generate tests and discover existing defects in your application!

See also

• Language syntax

• Available actions

To cite Concordia in a paper, please cite its PhD Thesis:

Concordia Compiler infers test cases, test data and test oracles from specification files written in Concordia and tries to cover a large number of paths that can expose defects in your application. Its approach keeps the specification relevant, up-to-date and more useful for stakeholders, testers, and developers than other documentation formats.

Usage cycle

We recommend the following usage cycle:

1. Write or update your requirements specification with the Concordia Language and validate them with users or stakeholders;

2. Use Concordia Compiler for generating functional tests from the specification and running them;

3. If the tests failed, there are some possibilities:

   a) You still haven't implemented the corresponding behavior in your application. In this case, just implement it and run the tests again.

   b) Your application is behaving differently from the specification. In this case, it may have bugs or you or your team haven't implemented the behavior exactly like described in the specification.

   • Whether the application has a bug, we are happy to have discovered it! Just fix it and run the tests again to make sure that the bug is gone.

   • Otherwise, you can decide between changing your application to behave exactly like the specification describes, or changing the specification to match your application behavior. In the latter case, back to step 1.

4. If the tests passed, great job! Now you can write new requirements or add more test cases, so just back to step 1.

Process

When you type concordia, the compiler performs the following process:

1. It reads your .feature and .testcase files, and uses a and a to identify and check documents' structure.

2. It uses (NLP) to identify sentences' , which increases the chances of recognizing different writing styles.

3. It performs to check recognized declarations.

4. It uses the specification to infer the most suitable test cases, test data, and test oracles, and then generates .testcase files in Concordia Language.

5. It transforms all the test cases into test scripts (that is, source code) using a plug-in.

6. It executes the test scripts with the plug-in. These test scripts will check your application's behavior through its user interface.

7. It reads and presents execution results. These results relate failing tests to the specification, in order to help you understanding the possible reasons of a failure.

Concordia Language contains a set of meta-actions that can be used by different testing frameworks for generating test scripts. Concordia Compiler uses Intent Recognition (yes, like chatbots do) to understand sentences and extract the desired action to perform. Later these actions are sent to testing frameworks for conversion into commands.

The following list presents the available actions and gives some examples on how to use them in sentences. We expect that you do not have to memorize them but, instead, see the things you can do. Try to write the sentences the way you speak, using first person singular (I) . When there is a UI Element in the sentence, embrace it with { and }, like {this}. The compiler will tell you whether it cannot understand some sentence you wrote. If you think it should have understood something, . We'll try to augment the compiler's vocabulary to understand it the next time.

accept

Accepts a browser message or app message.

amOn

Indicates a webpage or screen in which it is expected to be at.

append

Adds a value to an element.

attachFile

Attaches a file. It selects a file and confirms its choice (e.g., clicks Open).

cancel

Cancels a browser message or app message.

check

Checks a checkbox.

clear

Empties an input field or browser cookie

click

Clicks on something in the screen.

close

Closes a tab, a set of tabs, or an app (mobile only).

connect

Connects to a database.

The next sentence is for only:

disconnect

Disconnects from a database.

The next sentence is for only:

doubleClick

Performs a double click on something.

drag

Drags and drops something to a widget.

fill

Indicates that a field is being filled. If desired, a value can be given. Otherwise, a value will be generated for the corresponding Test Case.

fill + target

hide

Hides something.

install

Installs an app.

maximize

Maximizes a window or the browser.

move

Moves the mouse cursor to a place or element.

open

Opens something

press

Presses a key or key combination, separated by comma.

Some special keys (case sensitive!):

• Add

• Alt

• ArrowDown or Down arrow

• ArrowLeft or Left arrow

• ArrowRight or Right arrow

• ArrowUp or Up arrow

• Backspace

• Command

• Control

• Del

• Divide

• End

• Enter

• Equals

• Escape

• F1 to F12

• Home

• Insert

• Meta

• Multiply

• Numpad 0 to Numpad 9

• Pause

• Pagedown or PageDown

• Pageup or PageUp

• Semicolon

• Shift

• Space

• Subtract

• Tab

pull

Extracts a device's resource from a path.

refresh

Refreshes/reloads the current page.

remove

Removes/uninstall an app by its internal name (mobile only).

resize

Resizes a window.

rightClick

Performs a right click on something.

run

Runs a console command or a database script (SQL command).

👉 Available for only.

👉 Commands and SQL scripts must be declared between single quotes ('), in a single line.

👉 SQL scripts must reference their database.

SQL Syntax

Concordia Compiler uses to access databases and files through SQL-like commands. The supported SQL syntax may vary from one database to another. Please see the .

JSON and CSV as databases: INSERT accepts JSON objects or arrays as values. Example:

Excel and Firebase databases: Syntax similar to JSON and CSV databases. However, it has some limitations, as pointed out in :

SQL commands are limited to SELECT, UPDATE, INSERT and DELETE. WHERE works well. JOINs are not allowed. GROUP BY is not supported. LIMIT and OFFSET are combined into a single LIMIT syntax: LIMIT [offset,]number

INI databases: INSERT and DELETE are not supported yet by . UPDATE example:

SQLite databases: Currently uses that doesn't persist the changes in the file (only in memory).

saveScreenshot

Takes a screenshot an saves into a file.

scrollTo

Scrolls to a certain element.

see

Indicates that something can be seen. You can also negate the sentence to indicate something cannot be seen.

select

Selects a value for an element.

shake

Shakes the device - MOBILE ONLY.

swipe

Performs a swipe action - MOBILE ONLY

switch

• Switches to a certain iframe and back to the application page; OR

• Switches to a certain tab; OR

• Switches an app to native mode or web mode - MOBILE ONLY.

NOTE: When switching to an iframe, all the commands that follow it will be applied to it.

tap

Performs a tap on an element - MOBILE ONLY

uncheck

Unchecks a checkbox.

wait

Wait for something.

⚠ UNDER CONSTRUCTION ⚠

In software testing, test coverage is some kind of metric that helps you to understand what parts of your application (or code) are exercised by your tests. The number of feasible paths through them grows exponentially with an increase in application size and can even be infinite in the case of applications with unbounded loop iterations. That is a problem called path explosion problem. Concordia Compiler deals with it by providing sets of combination and selection strategies, and trying to achieve full path coverage over time.

Test Coverage

• All the Features, Scenarios, and Variants are covered by default.

• The CLI parameter --files can filter the .feature files to be considered.

• The CLI parameter --ignore can indicate the .feature files to be ignored, when a directory is given.

• The @ignore can be used to mark a Feature or Variant to be ignored by the test generator. However, it can still be used by other Features or Variants.

• The @importance (e.g., @importance( 8 )) can be used to denote the importance of a Feature. CLI parameters --sel-min-feature and --sel-max-feature can then be used to filter the features to be considered by the test generator. Example: concordia --sel-min-feature 7 makes the compiler considers the features with importance value of 7 or above. By default, all the features receive an importance value of 5.

• Variants are selected and combined using State-based Strategies (see below).

• All the UI Elements constraints are covered by default, using a set of Testing Techniques (see below).

State-based Strategies

In Concordia, you can declare a State in a Variant sentence using a text between tile (~), like this:

There are three types of State:

1. Precondition: when declared in a Given sentence;

2. State Call: when declared in a When sentence;

3. Postcondition: when declared in a Then sentence.

Both Preconditions and State Calls are considered required States. That is, they denote a dependency of a certain State of the system that needs to be executed. A Precondition needs to be executed before the Variant starts, and a State Call needs to be executed during the Variant's execution.

A Postcondition is a produced State, that is, a state of the system produced by a successful execution of a Variant. Therefore, whether something goes wrong during a Variant's execution, it will not produce the declared State.

When the current Variant requires a State, Concordia Compiler will look for imported Features' Variants able to produce it. To generate complete Test Cases for the current Variant, it will:

1. Select the Variants to combine;

2. Generate successful test scenarios for the selected Variants;

3. Select the successful test scenarios to combine;

4. Generate (successful and unsuccessful) test scenarios for the current Variant;

5. Combine the selected successful test scenarios with the test scenarios of the current Variant;

6. Transform all the test scenarios into test cases (i.e., valued test scenarios).

Steps 1 and 3 can adopt different strategies. Concordia Compiler let's you:

• Parameterize how the Variants will be selected, using --comb-variant; and

• Parameterize how the successful test scenarios will be combined, using --comb-state.

Variant selection

Available strategies for --comb-variant:

• random: Selects a random Variant that produces the required State. That's the default behavior;

• first: Selects the first Variant that produces the required State;

• fmi: Selects the first most important Variant (since two Variants can have the same importance value) that produces the required State;

• all: Selects all the Variants that produce the required State.

Example:

State combination

Available strategies for --comb-state:

• sre: Single random of each - that is, randomly selects a single, successful test scenario of each selected Variant. That's the default behavior;

• sow : Shuffled one-wise - that is, shuffles the successful test scenarios than uses combination.

• ow: selection;

• all: Selects all the successful test scenarios to combine.

Example:

Full vs random selection

Strategies that use random selection can take different paths every time they are used. Furthermore, they reduce considerably the amount of generated paths - i.e., it avoids "path explosion" - and thus the amount of produced test cases.

Full-selection strategies can be used for increase path coverage. Although, it also increases the needed time to check all the paths, which may be undesirable for frequent tests.

By default, Concordia Compiler uses random selection strategies.

Testing Techniques

Concordia Compiler can infer input test data from Variants, UI Elements, Constants, Tables, and Databases. The more constraints you declare, the more test cases it generates.

Adopted techniques to generate input test data include:

These are well-known, effective black-box testing techniques for discovering relevant defects on applications.

Data Test Cases

We call Data Test Cases those test cases used to generate input test data. They are classified into the following groups: RANGE, LENGTH, FORMAT, SET, REQUIRED, and COMPUTED. The group COMPUTEDis not available on purpose, since a user-defined algorithm to produce test data can have bugs on itself. Thus, one should provide expected input and output values in order to check whether the application is able to correctly compute the output value based on the received input value.

Every group has a set of related data test cases, applied according to the declared constraints and selected algorithms:

Maximum length for random string values

By default, the maximum length for randomly-generated string values is 500. This value is used for reducing the time to run test scripts, since long strings take time to be entered.

You can set maximum length using the CLI parameter --random-max-string-size. Example:

You can also set it in the configuration file (.concordiarc) by adding the property randomMaxStringSize. Example:

Properties vs Data Test Cases

Data Test Cases (DTC) are selected for every declared and its properties. The more properties you declare for a UI Element, the more data you provide for Concordia Compiler to generate DTC.

Example of some evalutations:

• When no properties are declared, FILLED and NOT_FILLED are both applied and considered as valid values;

• When the property required is declared, NOT_FILLED (empty) is considered as an invalid value;

• When the property value is declared:

  • if it comes from a set of values (inclusing a query result), all the DTC of the group SET are applied;

  • otherwise, ...

• When the property minimum value is declared:

Example 1

Let's describe a named Salary :

When no property is defined or only the property data typeis defined,

We defined the property data type as double, since the default data type is string.

Since few restrictions were made, Salary will be tested with the test cases of the group REQUIRED:

1. FILLED: a pseudo-random double value is generated;

2. NOT_FILLED: an empty value will be used.

Now let's add a minimum value restriction.

Some tests of the group RANGE are now applicable:

1. LOWEST_VALUE: the lowest possible double is used

2. RANDOM_BELOW_MIN_VALUE: a random double before the minimum value is generated

3. JUST_BELOW_MIN_VALUE: a double just below the minimum value is used (e.g., 999.99)

4. MIN_VALUE: the minimum value is used

5. JUST_ABOVE_MIN_VALUE: a double just above the minimum value is used (e.g., 1000.01)

6. ZERO_VALUE: zero (0) is used

Since 1000.00 is the minimum value, the data produced by the tests 1, 2, 3, and 6 of the group VALUE are considered invalid, while 4 and 5 are not. For these tests considered invalid, the behavior defined in Otherwise, that is

is expected to happen. In other words, this behavior serves as and must occur only when the produced value is invalid.

Unlike this example, when the expected system behavior for invalid values is not specified and a test data is considered invalid, Concordia expects that test should fail. In this case, it generates the Test Case with the tag @fail.

Now let's add maximum value restriction:

All the tests of the group RANGE are now applicable. That is, the following tests will be included:

1. MEDIAN_VALUE: the median between the minimum and the maximum values

2. RANDOM_BETWEEN_MIN_MAX_VALUES: a pseudo-random double value between the minimum and the maximum values

3. JUST_BELOW_MAX_VALUE: the value just below the maximum value

4. MAX_VALUE: the maximum value

5. JUST_ABOVE_MAX_VALUE: the value just above the maximum value

6. RANDOM_ABOVE_MAX_VALUE: a pseudo-random double above the maximum value

7. GREATEST_VALUE: the greatest possible double

The tests from 5 to 7 will produce values considered invalid.

Example 2

Let's define a user interface element named Profession and a table named Professions from which the values come from:

Applicable test are:

• FILLED

• NOT_FILLED

• FIRST_ELEMENT

• RANDOM_ELEMENT

• LAST_ELEMENT

• NOT_IN_SET

The first two tests are in the group REQUIRED. Since we declared Profession as having a required value, the test FILLED is considered valid but NOT_FILLED is not. Therefore, it is important to remember declaring required inputs accordingly.

The last four tests are in the group SET. Only the last one, NOT_IN_SET, will produce a value considered invalid.

Example 3

In this example, let's adjust the past two examples to make Salary rules dynamic and change according to the Profession.

Firstly, we add two columns the the Professions table:

Then, we change the rules to retrieve the values from the table:

The reference to the UI Element {Profession} inside the query, makes the rules of Salary depend on Profession. Every time a Profession is selected, the minimum value and the maximum value of Salary changes according to the columns min_salary and max_salary of the table Professions.

Tools

• is a browser extension for Chrome and Firefox that converts recordings from (which is a - that is, it records all the actions that you perform while interacting with the application under test in order the reproduce them later) to Variant sentences. That's very handful for discovering elements' identification in web applications (e.g., their id properties or their ) and obtaining Variant sentences with the corresponding interaction.

• is a command-line tool that generates User Interface Prototypes (UIP) from Concordia features. It can help discussing features with stakeholders and accelerating their construction. Currently there is a customizable plug-in for HTML-based interfaces.

• is a command-line tool that generates an HTML page with an interactive graph that shows features files' relationships.

Publications

1. PINTO, Thiago Delgado. Unifying Agile requirements specification quality control and implementation conformance assurance. 2018. Doctoral Thesis. Pontifical Catholic University of Rio de Janeiro, Informatics Department, 2018.

2. PINTO, Thiago Delgado; COSTA, Pablo Veiga; GONÇALVES, Willian Inácio. User Interface Prototype Generation from Agile Requirements Specifications written in Concordia. 2019. WebMedia'19: Proceedings on the 25th Brazilian Symposium on Multimedia and the Web, Rio de Janeiro, 2019. ACM. DOI:

Concordia Compiler can use a configuration file in named .concordiarc. You can generate it by running the following command:

You'll be asked about the desired configuration and then the file will be saved.

Example:

Configuration file's properties are similar to CLI parameters. The example above defines: "pt" (meaning "Portuguese") as the default language; the directory "docs/features" for features and test cases; the plug-in "codeceptjs-testcafe" for generating test scripts; the directory "test/e2e" for test scripts; and the directory "test/e2e/output" for output files such as report files and screenshots.

File-related options

directory

Directory to search for .feature and .testcase files.

Example:

recursive

Use recursive directory search.

Example:

files

Files to consider, instead of considering directory. The files must be separated by colon.

Example:

Another example:

ignore

Files to ignore, considering the parameter directory. The files must be separated by colon. Example:

extensions

To-Do

encoding

File encoding of the files. Accepted values are:

• utf8 or utf-8

• latin1

• ascii

• ucs2 or ucs-2

• utf16le or utf-16le

Naturally, the files must be edited with the given file encoding.

Language-related options

To-Do

Plug-in related options

To-Do

Processing-related options

To-Do

Generation-related options

To-Do

Strategy-related options

To-Do

Versioning

Concordia Compiler's versions are based on .

Although Semantic Versioning is conceived for s instead of for applications, we adopt a very similar convention. Thus, changes become predictable and you can know, from the version numbers, when a version is no more compatible with a previous version.

Given a version MAJOR.MINOR.UPDATE:

• MAIOR is increased when the Compiler or the Language is no more compatible with the previous version.

• MINOR is increased when adding functionality in a backwards-compatible manner.

• UPDATE is increased when there are fixes, little changes or little novelties - all of them backwards-compatible.

Examples:

• 0.2.0 is compatible with 0.1.0

• 0.1.1 is compatible with 0.1.0

• 1.0.0 is not compatible with 0.2.0

Upgrade

To upgrade a local installation:

To upgrade a global installation:

Information about breaking changes.

From 1.x to 2.x

Please read Issue #56.

From 0.x to 1.x

Concordia Compiler

1. It changed the way that all the plug-in operations are handled. See Issue #34 for details.

2. The behavior of the following plug-in commands were affected:

👉 See the Command Documentation to know the commands' syntax.

Concordia Language

No compatibility breaks.

Other relevant changes

External tools used by plug-ins are now installed locally, per project, instead of installed globally. Their direct execution (without using Concordia) is now possible through NPX. For instance, the command codeceptjs run test.js must now be executed as npx codeceptjs run test.js. This change also allows the installation of different versions of external tools, when needed.

FAQ

1. Were there any changes in commands' syntaxes?

   No, there were not.

2. Is my configuration file still compatible?

   It depends. All the properties are still compatible, except for "plugin". Whether your configuration file has that property, you should update it.

3. Is it possible now to install or uninstall a plug-in with NPM ?

   Yes, it is possible to do both now.

Migrations are only needed when upgrading to a major version. See Versions and Upgrade for more information.

To upgrade to a major version:

1. Uninstall the current version, e.g.: npm uninstall -D concordialang

2. Install the new version, e.g.: npm install -D concordialang

3. Now proceed as described below (depending on your current version).

Note: For a global installation, replace -D with -g.

From 1.x to 2.x

1. Update your plug-in

Concordia 2 has a new plugin API, not compatible with plug-ins for Concordia 1. So uninstall your current plug-in and install a new one. Example:

npx concordia --plugin-uninstall codeceptjs-webdriverio
npx concordia --plugin-install codeceptjs-webdriverio

Alternatively, you can install one of the new plug-ins then change your configuration file to use it. Example:

npx concordia --plugin-uninstall codeceptjs-webdriverio
npx concordia --plugin-install codeceptjs-playwright
npx concordia --plugin codeceptjs-playwright --save-config

2. Install database drivers

Whether your Concordia specification access a database, you have to install the corresponding database driver. Concordia 2 does not install them by default anymore, as Concordia 1 did, aiming to reduce the amount of downloaded dependencies.

Concordia 2 has a new CLI option --db-install to help with that. Example:

npx concordia --db-install mysql

See Database Drivers to install the proper driver(s) for your application.

From 0.x to 1.x