| Name | robotframework-mbt JSON |
| Version |
0.5.0
JSON |
| download |
| home_page | None |
| Summary | Model-Based Testing in Robot framework with test case generation |
| upload_time | 2024-10-28 11:37:47 |
| maintainer | None |
| docs_url | None |
| author | None |
| requires_python | >=3.10 |
| 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 is executable as a [Robot framework](https://robotframework.org/) test suite. Current capabilities focus around sequencing complete scenarios and action refinement for when-steps. 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 (for now) be composable into a single complete sequence, without leftovers. The same scenario can be inserted multiple times if repetition helps to reach the entry condition for later scenarios.
## 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
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 has no dependencies and can be executed at any time. This is evident from the fact that the scenario does not have any given-steps. From the `*model info*` we see that no dependencies need to be resolved before going into the first step: _When you buy a new postcard_. This is indicated by the `:IN:` condition which is `None`. After completing the step, a new domain term is available, `postcard`, as a result of the `:OUT:` statement `new postcard`. The following then-step adds detail to the postcard by adding a property. Setting `postcard.wish=None` in the `:OUT:` statement indicates that _you have a blank postcard_.
The second scenario has a dependency to the first scenario, due to the given-step: _Given you have a blank postcard_. This is expressed by the `:IN:` expression stating that you need a postcard, that does not have a wish on it yet. 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 cannot be executed at the current time. 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. The step implementations use keywords to connect to the system under test. The keywords perform actions or check the specified behaviour.
You can keep your models clean by deleting domain terms that are no longer relevant (e.g. `del postcard`). If multiple expressions are needed you can separate them in the `*model info*` by using the pipe symbol (`|`) or starting the next expression on a new line. A single expression cannot be split over multiple lines.
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:` expression is a condition. The `:OUT:` part is either identical to the `:IN:` condition or a statement. Statements, like assigning a new property, are useful to express the result of a scenario. If the when-action is setting the property, then you use a condition in the `:OUT:` part. The step implementation of stative steps 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 ***
Library robotmbt
Suite Setup Treat this test suite model-based
```
Disclaimer: 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": null,
"name": "robotframework-mbt",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.10",
"maintainer_email": null,
"keywords": "robotframework, robot, mbt, bdd, testing",
"author": null,
"author_email": "Johan Foederer <github@famfoe.nl>",
"download_url": "https://files.pythonhosted.org/packages/4c/36/19cb9059b4726d93c5387eade8ba4d674e7352ca9471e09e9b808238131a/robotframework_mbt-0.5.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 is executable as a [Robot framework](https://robotframework.org/) test suite. Current capabilities focus around sequencing complete scenarios and action refinement for when-steps. 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 (for now) be composable into a single complete sequence, without leftovers. The same scenario can be inserted multiple times if repetition helps to reach the entry condition for later scenarios.\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\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 has no dependencies and can be executed at any time. This is evident from the fact that the scenario does not have any given-steps. From the `*model info*` we see that no dependencies need to be resolved before going into the first step: _When you buy a new postcard_. This is indicated by the `:IN:` condition which is `None`. After completing the step, a new domain term is available, `postcard`, as a result of the `:OUT:` statement `new postcard`. The following then-step adds detail to the postcard by adding a property. Setting `postcard.wish=None` in the `:OUT:` statement indicates that _you have a blank postcard_.\r\n\r\nThe second scenario has a dependency to the first scenario, due to the given-step: _Given you have a blank postcard_. This is expressed by the `:IN:` expression stating that you need a postcard, that does not have a wish on it yet. 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 cannot be executed at the current time. 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. The step implementations use keywords to connect to the system under test. The keywords perform actions or check the specified behaviour.\r\n\r\nYou can keep your models clean by deleting domain terms that are no longer relevant (e.g. `del postcard`). If multiple expressions are needed you can separate them in the `*model info*` by using the pipe symbol (`|`) or starting the next expression on a new line. A single expression cannot be split over multiple lines.\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:` expression is a condition. The `:OUT:` part is either identical to the `:IN:` condition or a statement. Statements, like assigning a new property, are useful to express the result of a scenario. If the when-action is setting the property, then you use a condition in the `:OUT:` part. The step implementation of stative steps 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\nLibrary robotmbt\r\nSuite Setup Treat this test suite model-based\r\n```\r\n\r\nDisclaimer: 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.\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.5.0",
"project_urls": {
"Homepage": "https://github.com/JFoederer/robotframeworkMBT"
},
"split_keywords": [
"robotframework",
" robot",
" mbt",
" bdd",
" testing"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "b10dfe5d3f47b4f1f5955b1eced3acd1712fa395675d9eaa5f0b2fe605a047b3",
"md5": "bc92ddeaefcbdb2cc2523eaffa6f9824",
"sha256": "9711f5823c19d8caebe53049fbe11b5a47e1e66d7cae4327a4f00b61fcaeda61"
},
"downloads": -1,
"filename": "robotframework_mbt-0.5.0-py3-none-any.whl",
"has_sig": false,
"md5_digest": "bc92ddeaefcbdb2cc2523eaffa6f9824",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.10",
"size": 22820,
"upload_time": "2024-10-28T11:37:46",
"upload_time_iso_8601": "2024-10-28T11:37:46.072031Z",
"url": "https://files.pythonhosted.org/packages/b1/0d/fe5d3f47b4f1f5955b1eced3acd1712fa395675d9eaa5f0b2fe605a047b3/robotframework_mbt-0.5.0-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "4c3619cb9059b4726d93c5387eade8ba4d674e7352ca9471e09e9b808238131a",
"md5": "fee46abaa9149f9a5cc5d260e29878a9",
"sha256": "ffc7a2875fb70b779f4e77ee4a392d83ceac2d1ba134108f03c53ee7927e19b6"
},
"downloads": -1,
"filename": "robotframework_mbt-0.5.0.tar.gz",
"has_sig": false,
"md5_digest": "fee46abaa9149f9a5cc5d260e29878a9",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.10",
"size": 14481,
"upload_time": "2024-10-28T11:37:47",
"upload_time_iso_8601": "2024-10-28T11:37:47.716281Z",
"url": "https://files.pythonhosted.org/packages/4c/36/19cb9059b4726d93c5387eade8ba4d674e7352ca9471e09e9b808238131a/robotframework_mbt-0.5.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-10-28 11:37:47",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "JFoederer",
"github_project": "robotframeworkMBT",
"travis_ci": false,
"coveralls": false,
"github_actions": false,
"lcname": "robotframework-mbt"
}
