| Name | robotframework-mbt JSON |
| Version |
0.3.0
JSON |
| download |
| home_page | |
| Summary | Model-Based Testing in Robot framework with test case generation |
| upload_time | 2023-01-08 12:33:33 |
| maintainer | |
| docs_url | None |
| author | |
| requires_python | >=3.8 |
| license | BSD 3-Clause License Copyright (c) 2022, J. Foederer All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. |
| keywords |
robotframework
robot
mbt
bdd
testing
|
| VCS |
|
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
No coveralls.
|
# robotframeworkMBT - the oneliner
Model-based testing in Robot framework with test case generation
## Introduction
This project is an extension to [Robot framework](https://robotframework.org/) for model-based testing. The term model-based testing, or MBT in short, has been used in many different ways. Within this context two modelling aspects are most important. The first is about domain modelling using a domain specific language, or DSL. [Robot framework](https://robotframework.org/) already has great support for this aspect, which is why it was used as a base. The second aspect is about test case generation.
Test case generation introduces a more dynamic approach to executing a test suite. A typical traditional test suite is executed front to back. For maintainability reasons, test cases are often kept independent of each other. The down side to this approach is that there is little variation and often a lot of duplication, mostly during the setup phases.
With this project we aim to get the best of both worlds. Allowing testers to write small, independent cases that are automatically combined. Finding more issues in less time, by focusing on effectively reaching the desired coverage.
## Installation
The recommended installation method is using [pip](http://pip-installer.org)
pip install --upgrade robotframework-mbt
After installation include `robotmbt` as library in your robot file to get access to the new functionality.
## Capabilities
To get a feel for what this library can do, have a look at our [Titanic themed demo](https://github.com/JFoederer/robotframeworkMBT/tree/main/demo/Titanic), that his executable as a [Robot framework](https://robotframework.org/) test suite. Current capabilities focus around complete scenarios. When all steps are properly annotated with modelling info, the library can resolve their dependencies to figure out the correct execution order. To be successful, the set of scenarios in the model must be composable into a single complete sequence, without repetitions or leftovers.
## How to model
Modelling can be done directy from [Robot framework](https://robotframework.org/), without the need for additional tooling. The popular _Given-When-Then_ style is used to capture behaviour in scenarios. Consider these two scenarios:
```
Buying a postcard
When you buy a new postcard
then you have a blank postcard
Preparing for a birthday party
Given you have a blank postcard
When you write 'Happy birthday!' on the postcard
then you are ready to go to the birthday party
```
Mapping the dependencies between scenarios is done by annotating the steps with modelling info. Modelling info is added to the documentation of the step as shown below. Regular documentation can still be added, as long as `*model info*` starts on a new line and a whiteline is included after the last `:OUT:` expressions.
```
you buy a new postcard
[Documentation] *model info*
... :IN: None
... :OUT: new postcard | postcard.wish=None
you have a blank postcard
[Documentation] *model info*
... :IN: postcard.wish==None
... :OUT: postcard.wish==None
you write '${your_wish}' on the postcard
[Documentation] *model info*
... :IN: postcard.wish==None
... :OUT: postcard.wish=${your_wish}
```
The first scenario can be executed directly. It has no dependencies that need to be resolved before going into its first step, as indicated by the `:IN:` expression which is `None`. After completing the step, a new domain term is available with a single property. The term `postcard` with property `wish` is introduced, as stated by the `:OUT:` expressions. This satisfies the condition for the then-step to complete this scenario.
The second scenario has a dependency to the first scenario, due to the condition stated in the given-step of the scenario. How this works is by evaluating the expressions according to this schema:
* given-steps evaluate only the `:IN:` expressions
* when-steps evaluate both the `:IN:` and `:OUT:` expressions
* then-steps evaluate only the `:OUT:` expressions
If evaluation of any expression fails or is False, then the scenario is rejected. By properly annotating all steps to reflect their impact on the system or its environment, you can model the intended relations between scenarios. This forms the specification model. You can keep your models clean by deleting terms (e.g. `del postcard`) that are no longer relevant. The step implementations use keywords to connect to the system under test to verify the specified behaviour.
There are three typical kinds of steps
* __Stative__
Stative steps express a truth value. Like _you have a blank postcard_ For these steps the `:IN:` and `:OUT:` expressions have identical conditions and the step implementation consists purely of checks.
* __Action__
Action steps perform an action on the system that alters its state. These steps can have dependencies in their `:IN:` conditions that are needed to complete the action. Statements in the `:OUT:` expressions indicate what changes are expected by executing this action.
* __Refinement__
Action refinement allows you to build hierarchy into your scenarios. The `:IN:` and `:OUT:` expressions are only conditions (checks), but the `:IN:` and `:OUT:` expressions are different. If for any step the `:OUT:` expression is reached for evaluation, but fails, this signals the need for refinement. A single full scenario can be inserted if all conditions match at the current position and the pending `:OUT:` conditions are satisfied after insertion.
Finally, to run your scenarios model-based, import `robotmbt` as a library and use the __Treat this test suite model-based__ keyword as suite setup. You are now ready to run your modelled test suite.
```
*** Settings ***
Suite Setup Treat this test suite model-based
Library robotmbt
```
Please note that this library is in a premature state and hasn't reached its first official release yet. Developments are ongoing within the context of the [TiCToC](https://tictoc.cs.ru.nl/) research project. Interface changes are still frequent and no deprecation warnings are being issued yet.
Raw data
{
"_id": null,
"home_page": "",
"name": "robotframework-mbt",
"maintainer": "",
"docs_url": null,
"requires_python": ">=3.8",
"maintainer_email": "",
"keywords": "robotframework,robot,mbt,bdd,testing",
"author": "",
"author_email": "Johan Foederer <github@famfoe.nl>",
"download_url": "https://files.pythonhosted.org/packages/bf/9b/4071c1b7929b8a58f133a31148016450cca5ed3839f154f8ad44d47d5158/robotframework-mbt-0.3.0.tar.gz",
"platform": null,
"description": "# robotframeworkMBT - the oneliner\r\n\r\n Model-based testing in Robot framework with test case generation\r\n\r\n## Introduction\r\n\r\nThis project is an extension to [Robot framework](https://robotframework.org/) for model-based testing. The term model-based testing, or MBT in short, has been used in many different ways. Within this context two modelling aspects are most important. The first is about domain modelling using a domain specific language, or DSL. [Robot framework](https://robotframework.org/) already has great support for this aspect, which is why it was used as a base. The second aspect is about test case generation.\r\n\r\nTest case generation introduces a more dynamic approach to executing a test suite. A typical traditional test suite is executed front to back. For maintainability reasons, test cases are often kept independent of each other. The down side to this approach is that there is little variation and often a lot of duplication, mostly during the setup phases.\r\n\r\nWith this project we aim to get the best of both worlds. Allowing testers to write small, independent cases that are automatically combined. Finding more issues in less time, by focusing on effectively reaching the desired coverage.\r\n\r\n## Installation\r\n\r\nThe recommended installation method is using [pip](http://pip-installer.org)\r\n\r\n pip install --upgrade robotframework-mbt\r\n\r\nAfter installation include `robotmbt` as library in your robot file to get access to the new functionality.\r\n\r\n## Capabilities\r\n\r\nTo get a feel for what this library can do, have a look at our [Titanic themed demo](https://github.com/JFoederer/robotframeworkMBT/tree/main/demo/Titanic), that his executable as a [Robot framework](https://robotframework.org/) test suite. Current capabilities focus around complete scenarios. When all steps are properly annotated with modelling info, the library can resolve their dependencies to figure out the correct execution order. To be successful, the set of scenarios in the model must be composable into a single complete sequence, without repetitions or leftovers.\r\n\r\n## How to model\r\n\r\nModelling can be done directy from [Robot framework](https://robotframework.org/), without the need for additional tooling. The popular _Given-When-Then_ style is used to capture behaviour in scenarios. Consider these two scenarios:\r\n\r\n```\r\nBuying a postcard\r\n When you buy a new postcard\r\n then you have a blank postcard\r\n\r\nPreparing for a birthday party\r\n Given you have a blank postcard\r\n When you write 'Happy birthday!' on the postcard\r\n then you are ready to go to the birthday party\r\n```\r\n\r\nMapping the dependencies between scenarios is done by annotating the steps with modelling info. Modelling info is added to the documentation of the step as shown below. Regular documentation can still be added, as long as `*model info*` starts on a new line and a whiteline is included after the last `:OUT:` expressions.\r\n\r\n```\r\nyou buy a new postcard\r\n [Documentation] *model info*\r\n ... :IN: None\r\n ... :OUT: new postcard | postcard.wish=None\r\n\r\nyou have a blank postcard\r\n [Documentation] *model info*\r\n ... :IN: postcard.wish==None\r\n ... :OUT: postcard.wish==None\r\n\r\nyou write '${your_wish}' on the postcard\r\n [Documentation] *model info*\r\n ... :IN: postcard.wish==None\r\n ... :OUT: postcard.wish=${your_wish}\r\n```\r\n\r\nThe first scenario can be executed directly. It has no dependencies that need to be resolved before going into its first step, as indicated by the `:IN:` expression which is `None`. After completing the step, a new domain term is available with a single property. The term `postcard` with property `wish` is introduced, as stated by the `:OUT:` expressions. This satisfies the condition for the then-step to complete this scenario.\r\n\r\nThe second scenario has a dependency to the first scenario, due to the condition stated in the given-step of the scenario. How this works is by evaluating the expressions according to this schema:\r\n\r\n* given-steps evaluate only the `:IN:` expressions\r\n* when-steps evaluate both the `:IN:` and `:OUT:` expressions\r\n* then-steps evaluate only the `:OUT:` expressions\r\n\r\nIf evaluation of any expression fails or is False, then the scenario is rejected. By properly annotating all steps to reflect their impact on the system or its environment, you can model the intended relations between scenarios. This forms the specification model. You can keep your models clean by deleting terms (e.g. `del postcard`) that are no longer relevant. The step implementations use keywords to connect to the system under test to verify the specified behaviour.\r\n\r\nThere are three typical kinds of steps\r\n\r\n* __Stative__ \r\n Stative steps express a truth value. Like _you have a blank postcard_ For these steps the `:IN:` and `:OUT:` expressions have identical conditions and the step implementation consists purely of checks.\r\n* __Action__ \r\n Action steps perform an action on the system that alters its state. These steps can have dependencies in their `:IN:` conditions that are needed to complete the action. Statements in the `:OUT:` expressions indicate what changes are expected by executing this action.\r\n* __Refinement__ \r\n Action refinement allows you to build hierarchy into your scenarios. The `:IN:` and `:OUT:` expressions are only conditions (checks), but the `:IN:` and `:OUT:` expressions are different. If for any step the `:OUT:` expression is reached for evaluation, but fails, this signals the need for refinement. A single full scenario can be inserted if all conditions match at the current position and the pending `:OUT:` conditions are satisfied after insertion.\r\n\r\nFinally, to run your scenarios model-based, import `robotmbt` as a library and use the __Treat this test suite model-based__ keyword as suite setup. You are now ready to run your modelled test suite.\r\n```\r\n*** Settings ***\r\nSuite Setup Treat this test suite model-based\r\nLibrary robotmbt\r\n```\r\n\r\nPlease note that this library is in a premature state and hasn't reached its first official release yet. Developments are ongoing within the context of the [TiCToC](https://tictoc.cs.ru.nl/) research project. Interface changes are still frequent and no deprecation warnings are being issued yet.\r\n",
"bugtrack_url": null,
"license": "BSD 3-Clause License Copyright (c) 2022, J. Foederer All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ",
"summary": "Model-Based Testing in Robot framework with test case generation",
"version": "0.3.0",
"split_keywords": [
"robotframework",
"robot",
"mbt",
"bdd",
"testing"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "50970b1f7d3e09ebae151900380a4d89404823606424a9015e7f6650e3571224",
"md5": "cd5c0cc7acfce829612f89a8aefd27c0",
"sha256": "6df8d7a693b96a5be0b1990b21082e5afb7109b8aaf895d5d555a0bd3fa681a2"
},
"downloads": -1,
"filename": "robotframework_mbt-0.3.0-py3-none-any.whl",
"has_sig": false,
"md5_digest": "cd5c0cc7acfce829612f89a8aefd27c0",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.8",
"size": 19648,
"upload_time": "2023-01-08T12:33:32",
"upload_time_iso_8601": "2023-01-08T12:33:32.477591Z",
"url": "https://files.pythonhosted.org/packages/50/97/0b1f7d3e09ebae151900380a4d89404823606424a9015e7f6650e3571224/robotframework_mbt-0.3.0-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "bf9b4071c1b7929b8a58f133a31148016450cca5ed3839f154f8ad44d47d5158",
"md5": "3175a8a8ef738406353c52a3b0be3111",
"sha256": "951b29340d47db0aa60ad33f8d69a878f8363367a19a10f939a39985c97c470c"
},
"downloads": -1,
"filename": "robotframework-mbt-0.3.0.tar.gz",
"has_sig": false,
"md5_digest": "3175a8a8ef738406353c52a3b0be3111",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.8",
"size": 12526,
"upload_time": "2023-01-08T12:33:33",
"upload_time_iso_8601": "2023-01-08T12:33:33.958346Z",
"url": "https://files.pythonhosted.org/packages/bf/9b/4071c1b7929b8a58f133a31148016450cca5ed3839f154f8ad44d47d5158/robotframework-mbt-0.3.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-01-08 12:33:33",
"github": false,
"gitlab": false,
"bitbucket": false,
"lcname": "robotframework-mbt"
}
