docs(*): use spelling device, vDevice, feature, scenario, `se…

…tup` & `connection` everywhere

doc/source/api/connections.rst

@@ -11,7 +11,7 @@ see :ref:`Connections`.
 Basic ``Connection``
 ====================
 
-The basic :class:`Connection` class is the master class of every Connection. It can always be used as container for
+The basic :class:`Connection` class is the master class of every connection. It can always be used as container for
 your sub-tree connection too.
 
 .. autoclass:: balder.Connection

doc/source/api/devices.rst

@@ -7,7 +7,7 @@ Every :class:`Scenario` and every :class:`Setup` describes a construction that c
 Basic ``Device``
 ================
 
-The basic :class:`Device` class is the master class of every Device object.
+The basic :class:`Device` class is the master class of every device object.
 
 .. autoclass:: balder.Device
     :members:

doc/source/api/features.rst

@@ -12,7 +12,7 @@ class.
 Basic ``Feature``
 =================
 
-The basic :class:`Feature` class is the master class of every Scenario.
+The basic :class:`Feature` class is the master class of every scenario.
 
 .. autoclass:: balder.Feature
     :members:

doc/source/api/scenarios.rst

@@ -8,7 +8,7 @@ Scenarios represents a abstract test setup, that is required to run a testmethod
 Basic ``Scenario``
 ==================
 
-The basic :class:`Scenario` class is the master class of every Scenario.
+The basic :class:`Scenario` class is the master class of every scenario.
 
 .. autoclass:: balder.Scenario
     :members:

doc/source/api/setups.rst

@@ -8,7 +8,7 @@ Setups describes real-world constellations of custom test environments. They con
 Basic ``Setup``
 ===============
 
-The basic :class:`Setup` class is the master class of every Setup.
+The basic :class:`Setup` class is the master class of every setup.
 
 .. autoclass:: balder.Setup
     :members:

doc/source/basics/connections.rst

@@ -21,7 +21,7 @@ especially the :class:`Connection` trees between the devices are important.
 
 This section shows the basic functionality of connections and how you can use them in the Balder ecosystem.
 
-Global Connection-Trees
+Global connection-trees
 =======================
 
 Internally Balder knows exactly how the connections are arranged with each other. For this it refers to the global
@@ -65,7 +65,7 @@ structure:
 
 Balder will automatically resolve UNRESOLVED sub-trees according to its current active global-connection-tree.
 
-OR/AND Connection relations
+OR/AND connection relations
 ===========================
 
 You can combine connection objects with each other. This makes it possible that a connection is based on a connection or
@@ -112,12 +112,12 @@ easier by refactoring the both **AND** relations:
 
 This limitation makes it easier to read the logic.
 
-Using the base Connection object
+Using the base connection object
 ================================
 
-You can use the base Connection object for different use cases.
+You can use the base connection object for different use cases.
 
-General Connection
+General connection
 ------------------
 
 If you want to specify that you need a connection, but it doesn't matter which connection type, you can use
@@ -131,7 +131,7 @@ This is the universal connection that describes a **can-be-everything** connecti
 
 **A general connection does never have based-on elements!**
 
-Container Connection
+Container connection
 --------------------
 
 Sometimes you want to create a statement AConnection OR BConnection. This can easily defined with an container
@@ -143,7 +143,7 @@ connection:
 
 **A container connection always has based-on elements**.
 
-Defining your own Connection
+Defining your own connection
 ============================
 
 Balder allows to define own connections. For that you have to provide a `connections` module somewhere in your project.
@@ -194,10 +194,10 @@ implement this easily:
 
 You are now able to use this connection. It is integrated in the project global connection tree.
 
-Global-Connection-Tree
+Global connection tree
 ======================
 
-In Balder all connections are embedded in a so called global-connection-trees. This tree defines how the connections are
+In Balder all connections are embedded in a so called global connection trees. This tree defines how the connections are
 arranged to each other.
 
 The global connection tree
@@ -207,7 +207,7 @@ Balder provides an global connection tree. This tree is already specified for al
 `<Connections API>`_). Per default Balder uses this pre-defined tree.
 
 .. note::
-    COMING SOON - We are working on a graphical tool to show this global-connection-tree.
+    COMING SOON - We are working on a graphical tool to show this global connection tree.
 
 ..
     .. todo

doc/source/basics/devices.rst

@@ -7,7 +7,7 @@ Devices
 
     Please note that this part of the documentation is not yet finished. It will still be revised and updated.
 
-A Device describes a single component of a :ref:`Scenario <Scenarios>` or of a :ref:`Setup <Setups>`. Generally they are
+A device describes a single component of a :ref:`Scenario <Scenarios>` or of a :ref:`Setup <Setups>`. Generally they are
 container classes for a collection of :ref:`Features`.
 
 Scenario-Device
@@ -17,7 +17,7 @@ A :ref:`Scenario-Device` is a device, that defines a subset of :ref:`Features`,
 have. Balder searches for matches (see also :ref:`Matching process of setups and scenarios (SOLVING)`), where the
 potential :ref:`Setup-Device` has an implementation for the :ref:`Features` of the :ref:`Scenario-Device`.
 
-So when is a :class:`Device` a Scenario-Device? - This depends one the definition location. A :class:`Device` is
+So when is a :class:`Device` a scenario-device? - This depends one the definition location. A :class:`Device` is
 a :ref:`Scenario-Device` when it is an inner-class of a :class:`Scenario`.
 
 .. code-block:: py
@@ -68,7 +68,7 @@ inner-classes in :ref:`Setups` of course.
 
 Often the :ref:`Features` of a :ref:`Setup-Device` implement the complete logic, while the features of the
 :ref:`Scenario-Device` only describes the abstract architecture. This can be done, because the :ref:`Features` of the
-:ref:`Setup-Devices <Setup-Device>` are subclasses of the Scenario-Device :ref:`Features`. You can find more
+:ref:`Setup-Devices <Setup-Device>` are subclasses of the scenario-device :ref:`Features`. You can find more
 information about this in the sections :ref:`Features` and :ref:`Matching process of setups and scenarios (SOLVING)`.
 
 

doc/source/basics/execution_mechanism.rst

@@ -18,7 +18,7 @@ an execution-tree. In the last step Balder executes this tree with the inclusion
 To make it easier to understand the functionality of Balder, we will start to consider the differences between
 :ref:`Setup <Setups>` classes and :ref:`Scenario <Scenarios>` classes a little bit more in detail.
 
-Difference between Setup and Scenario
+Difference between setup and scenario
 =====================================
 
 Balder is based on individual :ref:`Scenario <Scenarios>` and :ref:`Setup <Setups>` classes.
@@ -59,7 +59,7 @@ Collecting process
 The collection process is the first stage of the Balder execution mechanism, directly after executing the ``balder ...``
 command. In this stage all available relevant Balder classes within the working directory are collected.
 
-Collect Setups and Scenarios
+Collect setups and scenarios
 ----------------------------
 
 First the collector begins to find all setup and scenario classes that are located directly in the Python files
@@ -70,7 +70,7 @@ classes, which are subclasses of the master :class:`Scenario` class and if their
 Only for classes that meet all these criteria, Balder will acknowledge these classes as valid scenarios and add
 them to the internal collection of executable scenarios.
 
-In the same way, Balder searches for scenarios, it will do that for Setups. These setups have to be in files that have
+In the same way, Balder searches for scenarios, it will do that for setups. These setups have to be in files that have
 the name ``setup_*.py` and whose classes have the name ``Setup*`` and are child classes of :class:`Setup`.
 
 .. note::
@@ -83,14 +83,14 @@ With the previous step, Balder has automatically loaded all defined testcase met
 testcases have to be defined as a method in a :ref:`Scenario <Scenarios>` class. The name of these test methods always
 has to start with ``test_ *``. A scenario could define as much test methods as you like.
 
-Collect Connections
+Collect connections
 -------------------
 
 :ref:`Connections` are objects that connects devices with each other. These objects will be included in a global
 connection tree, which is the general representation of usable Balder connections. In every project you can define your
 own connections within python modules/files with the name ``connections``. These files will be read by Balder
 automatically during the collecting process. They will be inserted into the
-:ref:`global Connection-Tree <The global connection tree>`.
+:ref:`global connection-tree <The global connection tree>`.
 
 Matching process of setups and scenarios (SOLVING)
 ==================================================
@@ -240,15 +240,15 @@ two elements do not go together..
 
 They need some :ref:`Features`!
 
-Devices with Features
+Devices with features
 =====================
 
 In the previous step all our devices doesn't have a real functionality, they only exist. For this Balder provides
 :ref:`Features`. Features are classes that can be used by devices and offers functionality for these. If you have gone
 through the :ref:`Balder Intro Example` you have learned the basic functionality of features. For a full introduction
 to features, you can also discover the basic documentation section :ref:`Features`.
 
-Add Feature functionality
+Add feature functionality
 -------------------------
 
 So let us add some functionality to our scenario definition. For this we have to add some features. Get the rule back
@@ -302,7 +302,7 @@ the scenario can not be executed.
 Implement features in setup
 ---------------------------
 
-Of course we also need a feature implementation in our setups too. As you will see later, Features in
+Of course we also need a feature implementation in our setups too. As you will see later, features in
 :ref:`Scenario-Devices <Scenario-Device>` often only define the interface that is needed by the scenario-device, but we
 often do not provide a direct implementation of it there. Mostly the direct implementation is done on setup level.
 
@@ -484,14 +484,14 @@ of them. The following table shows them with the scope, they are valid.
 | ``balderglob.py`` file |                        | specific testset you are calling. This fixture will be executed in |
 |                        |                        | every test run.                                                    |
 +------------------------+------------------------+--------------------------------------------------------------------+
-| as method in           | only in this Setup     | This fixture runs only if this Setup will be executed in the       |
+| as method in           | only in this setup     | This fixture runs only if this setup will be executed in the       |
 | :class:`Setup`         |                        | current testrun. If the **execution-level** is ``session`` it will |
-|                        |                        | be executed as session-fixture only if this Setup is in the        |
+|                        |                        | be executed as session-fixture only if this setup is in the        |
 |                        |                        | executor tree. If the  **execution-level** is ``setup`` or lower,  |
 |                        |                        | this fixture will only be called if the setup is currently active  |
 |                        |                        | in the test run.                                                   |
 +------------------------+------------------------+--------------------------------------------------------------------+
-| as method in           | only in this Scenario  | This fixture runs only if this Scenario will be executed in the    |
+| as method in           | only in this scenario  | This fixture runs only if this scenario will be executed in the    |
 | :class:`Scenario`      |                        | current testrun. If the **execution-level** is ``session`` or      |
 |                        |                        | `setup` it will be executed as session-/ or setup-fixture only if  |
 |                        |                        | this Scenario is in the executor tree. If the  **execution-level** |

doc/source/basics/features.rst

@@ -24,7 +24,7 @@ To understand this more easily, let's take a look at the following example:
     class SenderFeature(balder.Feature):
 
         def send(msg):
-            raise NotImplementedError("this feature has to be implemented by feature class of Setup")
+            raise NotImplementedError("this feature has to be implemented by feature class of setup")
 
 
 .. code-block:: python
@@ -128,7 +128,7 @@ properties, they are only used to say:
 
 *This device has the feature ``IsRedFeature``*
 
-So we want to filter them, because we only want a match with a device that has the same Feature, but we can't or
+So we want to filter them, because we only want a match with a device that has the same feature, but we can't or
 don't want to influence or interact with this device over the autonomous :class:`.Feature`.
 
 The definition for such a autonomous feature, is really easy:
@@ -190,7 +190,7 @@ setup:
                 pass
 
 
-Bind Features
+Bind features
 =============
 
 A big advantage of Balder is that you are able to reuse components. This also applies to features. But mostly you will
@@ -207,10 +207,10 @@ to limit the allowed connections the feature is able to use with this :class:`VD
 This is the so called **class-based-binding**.
 
 In addition to that, it is also possible to bind single methods of your feature to a subset of the allowed sub-connection
-tree or/and for the usage with one VDevice only. This allows it to define a method multiple times with different
+tree or/and for the usage with one vDevice only. This allows it to define a method multiple times with different
 `@for_vdevice` bindings. So for example you can implement a method `send` that will be used if the device (that is
-assigned as VDevice) is connected over a TcpConnection. And additionally to that you have another method `send` that is
-bind to a `UdpConnection`. Depending on the current Scenario/Setup, Balder will use the correct method variation of
+assigned as vDevice) is connected over a TcpConnection. And additionally to that you have another method `send` that is
+bind to a `UdpConnection`. Depending on the current scenario/setup, Balder will use the correct method variation of
 `send`, after you call it in your testcase. This is the so called **method-based-binding**.
 
 This section describes how this mechanism generally works. You can find a lot of more detailed explanations in the
@@ -261,7 +261,7 @@ attribute ``OtherPipeVDevice="PipeDevice2"`` to the feature constructor to defin
 
 
 .. note::
-    Often you can not access the Device type objects inside the feature constructor. For this Balder also allows to use
+    Often you can not access the device type objects inside the feature constructor. For this Balder also allows to use
     simple strings, that contains the same name than the referencing device type.
 
 You can do this with different devices that could stand for different usages of this feature. So you can also add
@@ -294,7 +294,7 @@ way.
     Balder checks if the requirement that is given with the **Class-Based-Binding** is available. If the requirement
     doesn't match the class-based statement, it throws an error!
 
-How does that influence the Setup? - You are also able to define these vDevice-Device mapping in the setup. This is even
+How does that influence the setup? - You are also able to define these vDevice-Device mapping in the setup. This is even
 often the case, because your setup normally uses the specific functionality. Your scenario should be as universal as
 possible. You can also use this mechanism on scenario level. If you want to find out more about this, take a look at the
 :ref:`VDevices and method-variations` section.
@@ -305,7 +305,7 @@ Method-Based-Binding
 Often it is required to provide different implementations for different vDevices or different sub-connection-trees in a
 feature. For this you can use **Method-Based-Binding**.
 
-Let's assume, we have a Feature that could send a message to another device. For this case, the connection type
+Let's assume, we have a feature that could send a message to another device. For this case, the connection type
 does not really matter, because the feature should support this requirement generally for every possible connection.
 So it is only important to test that the device can send a message to another device. It does not matter, how the
 feature send this message (at least at scenario level).
@@ -335,15 +335,15 @@ Basically our scenario level implementation looks like:
 
 
 
-As you can see, we have defined the inner VDevice ``OtherVDevice`` here. We want to use the feature
+As you can see, we have defined the inner vDevice ``OtherVDevice`` here. We want to use the feature
 ``RecvMessengerFeature`` with this vDevice. For this we instantiate it as class property of the ``OtherVDevice``. This
 allows us, to define the requirement the mapped device should implement already in this feature.
 
 .. note::
-    The elements given in the inner VDevice class definition is a **MUST HAVE**, which means that the statement has to
+    The elements given in the inner vDevice class definition is a **MUST HAVE**, which means that the statement has to
     be available in the mapped device later, otherwise it would throw an error.
 
-Till now the Scenario-Feature doesn't use some **Method-Based-Bindings**. This will change in a few moments, when we
+Till now the scenario-feature doesn't use some **Method-Based-Bindings**. This will change in a few moments, when we
 implement the setup-level representation of this feature.
 
 Before we take action for the setup implementation, we want to create a :ref:`Scenario <Scenarios>` using this newly
@@ -375,7 +375,7 @@ created feature. For this, we want to implement a example scenario with two devi
             assert all_messages[0] == SEND_DATA, "have not received the sent data
 
 As you can see we have created a mapping for the inner :class:`VDevice` to an real defined scenario :class:`Device`
-by using the name of the inner VDevice as key and the name of the real device as value in the constructor. We also
+by using the name of the inner vDevice as key and the name of the real device as value in the constructor. We also
 implement a basic test, that should check the communication.
 
 So let's start to implement the setup level. We can implement our earlier defined feature by simply inheriting from it.