README

pipeline coverage

Application config system.

Installation

composer require arnapou/behat

packagist 👉️ arnapou/behat

Introduction

This library takes advantage of arnapou/appcfg to "compile" arrays with contexts.

This allows us to easily use the appcfg syntax to process data to test matching etc ...

The library mainly provides a BehatTool object you can use in your context to process the data.

examples.feature

Feature: Examples of what we can achieve

  Background:
    # For the example, this context is also interpreted and compiled.

    # In a real scenario, for example, these context data would probably
    # come from the last json response of a http query.
    Given a common JSON used as context for all compilation examples
    """
    {
      "items": [1, 2, 3, 4, 5, 6, 7, 8, 9],
      "text": "Hello World",
      "date": "%int(:%date(U:2024-06-23T19:03:48+00:00)%)%",
      "user": { "name": "John", "age": 20 }
    }
    """

  Scenario: "Rows" layout

    # The compilation is done with the context of the background.
    When we compile these "rows"
      | column A                       | column B        | column C                 |
      | foo                            | %items.1%       | %(date)%                 |
      | %save(username:%(user.name)%)% | %(items.2)%     | %filter(upper:%(text)%)% |

    # Basic EQUAL comparison against the previous result
    Then the last compiled is equal to these "rows"
      | column A                       | column B        | column C                 |
      | foo                            | %int(2)%        | %int(1719169428)%        |
      | John                           | %int(3)%        | HELLO WORLD              |

    # Equivalent EQUAL comparison but with raw JSON (not compiled)
    And the last compiled is equal to this JSON
    """
    [{
      "column A": "foo",
      "column B": 2,
      "column C": 1719169428
    },{
      "column A": "John",
      "column B": 3,
      "column C": "HELLO WORLD"
    }]
    """

  Scenario: "Columns" layout with only 1 column

    # The compilation is done with the context of the background.
    When we compile these "columns"
      | row      | foo                            |
      | json     | %json(encode:%(user)%)%        |
      | name     | %cache(username)%              |
      | company  | %cache(user.company:unknown)%  |

    # Basic EQUAL comparison against the previous result
    Then the last compiled is equal to these "columns"
      | row      | foo                            |
      | json     | {"name":"John","age":20}       |
      | name     | John                           |
      | company  | unknown                        |

    # Equivalent EQUAL comparison but with raw JSON (not compiled)
    And the last compiled is equal to this JSON
    """
    {
      "row": "foo",
      "json": "{\"name\":\"John\",\"age\":20}",
      "name": "John",
      "company": "unknown"
    }
    """

  Scenario: "Columns" layout with multiple columns

    # The compilation is done with the context of the background.
    When we compile these "columns"
      | name     | John       | Sue        |
      | age      | %int(20)%  | %int(23)%  |
      | company  | Google     | Microsoft  |

    # Equivalent EQUAL comparison but with raw JSON (not compiled)
    And the last compiled is equal to this JSON
    """
    [{
      "name": "John",
      "age": 20,
      "company": "Google"
    },{
      "name": "Sue",
      "age": 23,
      "company": "Microsoft"
    }]
    """

  Scenario: Matching example

    # The table is "unfolded" before compilation, that does the contrary
    # of flatten, expanding the paths to keys and sub-keys, ...
    When we unfold and compile these "columns"
      | users.0.name      | %cache(username)%                |
      | users.0.age       | %(user.age)%                     |
      | users.1.name      | Sue                              |
      | users.1.age       | %int(21)%                        |
      | items.values      | %(items)%                        |
      | items.count       | %filter(length:%(items)%)%       |
      | date              | %date(Y-m-d:%(date)%)%           |

    # MATCHING comparison which is OK if it does not trigger an exception.
    # You may use either raw values, or matching processors like regex & between.
    Then the last compiled is matching these "columns"
      | users.0.age       | %regex(/^\d+$/)%                 |
      | users.1.age       | %between(20,22)%                 |
      | date              | 2024-06-23                       |

    # EQUAL comparison with raw JSON (not compiled)
    And the last compiled is equal to this JSON
    """
    {
      "users": [
        { "name": "John" , "age": 20 },
        { "name": "Sue"  , "age": 21 }
      ],
      "items": {
        "values": [ 1, 2, 3, 4, 5, 6, 7, 8, 9 ],
        "count": 9
      },
      "date": "2024-06-23"
    }
    """

Changelog versions

Start	Tag, Branch	Php
23/06/2024	1.x, main	8.3

arnapou / behat

Maintainers

Details

README

Installation

Introduction

examples.feature

Changelog versions