github.com/darrenli6/fabric-sdk-example@v0.0.0-20220109053535-94b13b56df8c/test/feature/README.rst (about) 1 Behave tests for Hyperledger Fabric Feature and System Tests 2 ============================================================ 3 4 .. image:: http://cdn.softwaretestinghelp.com/wp-content/qa/uploads/2007/08/regression-testing.jpg 5 6 Behave is a tool used for Behavior Driven Development (BDD) testing. It uses tests (feature files) written in a natural language called Gherkin. The tests are executed using python as the supporting code. 7 8 BDD is an agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project. Feel free to read more about `BDD`_. 9 10 .. _BDD: http://pythonhosted.org/behave/philosophy.html 11 12 13 This drectory contains a behave implementation of system and feature file testing for Hyperledger Fabric. 14 15 Full documentation and usage examples for Behave can be found in the `online documentation`_. 16 17 .. _online documentation: http://pythonhosted.org/behave/ 18 19 20 Continuous Integration (CI) Execution 21 ------------------------------------- 22 The following are links to the Jenkins execution of these tests: 23 * `daily`_ 24 * `weekly`_ 25 * `release`_ 26 27 .. _daily: https://jenkins.hyperledger.org/view/Daily 28 .. _weekly: https://jenkins.hyperledger.org/view/Weekly 29 .. _release: https://jenkins.hyperledger.org/view/Release 30 31 32 Pre-requisites 33 -------------- 34 You must have the following installed: 35 * `python`_ (You must have 2.7 due to package incompatibilities) 36 * `docker`_ 37 * `docker-compose`_ 38 39 Ensure that you have Docker for `Linux`_, `Mac`_ or `Windows`_ 1.12 or higher properly installed on your machine. 40 41 .. _python: https://www.python.org/ 42 .. _docker: https://www.docker.com/ 43 .. _docker-compose: https://docs.docker.com/compose/ 44 .. _Linux: https://docs.docker.com/engine/installation/#supported-platforms 45 .. _Mac: https://docs.docker.com/engine/installation/mac/ 46 .. _Windows: https://docs.docker.com/engine/installation/windows/ 47 48 You can install Behave and additional packages either using the ``scripts/install_behave.sh`` (useful for linux distros that use the apt packaging manager) or following the links for your specific OS environment. 49 * `pip`_ 50 * `python-setuptools`_ 51 * `python-dev`_ 52 * `build-essential`_ 53 * `behave`_ 54 * `google`_ 55 * `protobuf`_ 56 * `pyyaml`_ 57 58 .. _pip: https://packaging.python.org/installing/#requirements-for-installing-packages 59 .. _python-setuptools: https://packaging.python.org/installing/ 60 .. _python-dev: https://packaging.python.org/installing/ 61 .. _build-essential: http://py-generic-project.readthedocs.io/en/latest/installing.html 62 .. _behave: http://pythonhosted.org/behave/install.html 63 .. _google: https://pypi.python.org/pypi/google 64 .. _protobuf: https://pypi.python.org/pypi/protobuf/2.6.1 65 .. _pyyaml: https://pypi.python.org/pypi/PyYAML 66 .. _pykafka: https://pypi.python.org/pypi/pykafka 67 68 You should also clone the following repositories 69 * `hyperledger-fabric`_ 70 * `hyperledger-fabric-ca`_ 71 72 .. _hyperledger-fabric: https://github.com/hyperledger/fabric 73 .. _hyperledger-fabric-ca: https://github.com/hyperledger/fabric-ca 74 75 ================ 76 Using VirtualEnv 77 ================ 78 It is also possible to execute these tests using `virtualenv`_. This allows for you to control your environment and ensure that the version of python and any other environment settings will be exactly what is needed regardless of the environment of the native machine. 79 80 .. _virtualenv: http://docs.python-guide.org/en/latest/dev/virtualenvs/ 81 82 There are instructions for setting up a virtualenv for executing behave tests located at ``bddtests/README.md``. Once these steps are completed and you have successfully setup the ``behave_venv`` virtual environment, execute the following before executing these behave tests. 83 84 :: 85 86 $ workon behave_venv 87 88 89 Getting Started 90 --------------- 91 Before executing the behave tests, it is assumed that there are docker images and tools that have already been built. 92 93 ================ 94 Areas of Testing 95 ================ 96 BDD tests are testing functionality and feature behavior. With this in mind, the following are areas that we plan to be covered in these BDD tests: 97 * Basic setup (Happy Path) 98 * Orderer Functionality 99 * solo 100 * kafka 101 * Ledgers 102 * Endorser and committer peers 103 * Fabric-CA (used for SSL connections) 104 * Upgrades and Fallbacks 105 * Bootstrapping 106 * configtxgen 107 * cryptogen 108 * Growing and shrinking networks 109 * Stopping and Starting components 110 * … and more (such as different tooling, messages sizes, special scenarios) 111 112 The following are not covered in these BDD tests: 113 * scalability 114 * performance 115 * long running tests 116 * stress testing 117 * timed tests 118 119 120 ====================== 121 Building docker images 122 ====================== 123 When executing tests that are using docker-compose fabric-ca images, be sure to have the fabric-ca docker images built. You must perform a ``make docker`` in the ``/path/to/hyperledger/fabric-ca`` directory. 124 125 The docker images for ``peer``, ``orderer``, ``kafka``, and ``zookeeper`` are needed. You must perform a ``make docker`` in the ``/path/to/hyperledger/fabric`` directory. 126 127 128 ========================= 129 Building tool executables 130 ========================= 131 The **configtxgen** and **cryptogen** tools are used when bootstrapping the networks in these tests. As a result, you must perform a ``make configtxgen && make cryptogen`` in the ``/path/to/hyperledger/fabric`` directory. 132 133 134 How to Contribute 135 -------------------------- 136 137 .. image:: http://i.imgur.com/ztYl4lG.jpg 138 139 There are different ways that you can contribute in this area. 140 * Writing feature files 141 * Writing python test code to execute the feature files 142 * Adding docker-compose files for different network configurations 143 144 =================================== 145 How Do I Write My Own Feature File? 146 =================================== 147 The feature files are written by anyone who understands the requirements. This can be a business analyst, quality analyst, manager, developer, customer. The file describes a feature or part of a feature with representative examples of expected outcomes and behaviors. These files are plain-text and do not require any compilation. Each feature step maps to a python step implementation. 148 149 The following is an example of a simple feature file: 150 151 .. sourcecode:: gherkin 152 153 Feature: Test to ensure I take the correct accessory 154 Scenario: Test what happens on a rainy day 155 Given it is a new day 156 When the day is rainy 157 And the day is cold 158 Then we should bring an umbrella 159 Scenario Outline: Test what to bring 160 Given it is a new day 161 When the day is <weather> 162 Then we should bring <accessory> 163 Examples: Accessories 164 | weather | accessory | 165 | hot | swimsuit | 166 | cold | coat | 167 | cloudy | nothing | 168 169 170 Keywords that are used when writing feature files: 171 * **Feature** 172 * The introduction of the different feature test scenarios 173 * You can have multiple scenarios for a single feature 174 * **Scenario/Scenario Outline** 175 * The title and description of the test 176 * You can run the same test with multiple inputs 177 * **Given** 178 * Indicates a known state before any interaction with the system. 179 * **Avoid talking about user interaction.** 180 * **When** 181 * Key actions are performed on the system. 182 * This is the step which may or may not cause some state to change in your system. 183 * **Then** 184 * The observed and expected outcomes. 185 * **And** 186 * Can be used when layering any givens, whens, or thens. 187 188 189 ======================== 190 Writing python test code 191 ======================== 192 Feature steps used in the feature file scenarios are implemented in python files stored in the “steps” directory. As the python implementation code grows, fewer changes to the code base will be needed in order to add new tests. If you simply want to write feature files, you are free to do so using the existing predefined feature steps. 193 194 The behave implementation files are named '*<component>_impl.py*' and the utilities are named '*<action>_util.py*' in the steps directory. 195 196 Python implementation steps are identified using decorators which match the keyword from the feature file: 'given', 'when', 'then', and 'and'. The decorator accepts a string containing the rest of the phrase used in the scenario step it belongs to. 197 198 199 .. sourcecode:: python 200 201 >>> from behave import * 202 >>> @given('it is a new day') 203 ... def step_impl(context): 204 ... # Do some work 205 ... pass 206 >>> @when('the day is {weather}') 207 ... def step_impl(context, weather): 208 ... weatherMap = {'rainy': 'an umbrella', 209 ... 'sunny': 'shades', 210 ... 'cold': 'a coat'} 211 ... context.accessory = weatherMap.get(weather, "nothing") 212 >>> @then('we should bring {accessory}') 213 ... def step_impl(context, accessory): 214 ... assert context.accessory == accessory, "You're taking the wrong accessory!" 215 216 217 ==================== 218 Docker-Compose Files 219 ==================== 220 These docker composition files are used when setting up and tearing down networks of different configurations. Different tests can use different docker compose files depending on the test scenario. We are currently using `version 2 docker compose`_ files. 221 222 .. _version 2 docker compose: https://docs.docker.com/compose/compose-file/compose-file-v2/ 223 224 225 How to execute Feature tests 226 ---------------------------- 227 There are multiple ways to execute behave tests. 228 * Execute all feature tests in the current directory 229 * Execute all tests in a specific feature file 230 * Execute all tests with a specified tag 231 * Execute a specific test 232 233 234 **Executes all tests in directory** 235 :: 236 237 $ behave 238 239 **Executes specific feature file** 240 :: 241 242 $ behave mytestfile.feature 243 244 **Executes tests labelled with tag** 245 :: 246 247 $ behave -t mytag 248 249 **Executes a specific test** 250 :: 251 252 $ behave -n 'my scenario name' 253 254 255 Helpful Tools 256 ------------- 257 Behave and the BDD ecosystem have a number of `tools`_ and extensions to assist in the development of tests. These tools include features that will display what feature steps are available for each keyword. Feel free to explore and use the tools, depending on your editor of choice. 258 259 .. _tools: http://behave.readthedocs.io/en/latest/behave_ecosystem.html 260 261 262 Helpful Docker Commands 263 ----------------------- 264 * View running containers 265 * ``$ docker ps`` 266 * View all containers (active and non-active) 267 * ``$ docker ps -a`` 268 * Stop all Docker containers 269 * ``$ docker stop $(docker ps -a -q)`` 270 * Remove all containers. Adding the `-f` will issue a "force" kill 271 * ``$ docker rm -f $(docker ps -aq)`` 272 * Remove all images 273 * ``$ docker rmi -f $(docker images -q)`` 274 * Remove all images except for hyperledger/fabric-baseimage 275 * ``$ docker rmi $(docker images | grep -v 'hyperledger/fabric-baseimage:latest' | awk {'print $3'})`` 276 * Start a container 277 * ``$ docker start <containerID>`` 278 * Stop a containerID 279 * ``$ docker stop <containerID>`` 280 * View network settings for a specific container 281 * ``$ docker inspect <containerID>`` 282 * View logs for a specific containerID 283 * ``$ docker logs -f <containerID>`` 284 * View docker images installed locally 285 * ``$ docker images`` 286 * View networks currently running 287 * ``$ docker networks ls`` 288 * Remove a specific residual network 289 * ``$ docker networks rm <network_name>`` 290 291 .. Licensed under Creative Commons Attribution 4.0 International License 292 https://creativecommons.org/licenses/by/4.0/