fixed by review

docs/advanced/custom_output_handlers.rst

@@ -19,7 +19,7 @@ You can make your own Output Handler, following the next two steps:
   :class:`rotest.core.result.handlers.abstract_handler.AbstractResultHandler`,
   and overriding the relevant methods.
 
-* Register the above inheriting class as an entrypoint in your setup.py file inside ``Setup()``:
+* Register the above inheriting class as an entrypoint in your setup.py file inside ``setup()``:
 
     .. code-block:: python
 
@@ -38,6 +38,8 @@ You can make your own Output Handler, following the next two steps:
 For an example, you can refer to
 `rotest_reportportal <https://github.com/gregoil/rotest_reportportal>`_ plugin.
 
+.. _available_events:
+
 Available Events
 ================
 

docs/advanced/monitors.rst

@@ -12,19 +12,12 @@ The features of monitors:
 
 * They can be applied or dropped as easily as adding a new output handler to the list.
 
-* They save you writing validations that are needed in a group of similar tests.
+* They enable extending sets of tests with additional validations without altering their code.
 
 * They can run in the background (in another thread).
 
 A classic example is monitoring CPU usage during tests, or a resource's log file.
 
-.. note::
-
-    Monitors are associated with tests rather than the entire run,
-    so when running in multiprocess, they run in the workers' processes,
-    unlike normal output handlers which only run in the main process.
-
-
 Writing A Monitor
 =================
 
@@ -42,29 +35,30 @@ There are two types of monitors:
 
 * Monitors that only react to test events, e.g. taking a screen-shot on error.
 
-    Since monitors inherit from ``AbstractResultHandler``, you can react
-    to any test event by overriding the appropriate method.
+  Since monitors inherit from ``AbstractResultHandler``, you can react
+  to any test event by overriding the appropriate method.
 
-    See :ref:`advanced.custom_output_handlers` for a list of events.
+  See :ref:`available_events` for a list of events.
 
-    Each of those event methods get the test instance as the first parameter,
-    through which you can access its fields (test.<resource>, test.config, test.work_dir, etc.)
+  Each of those event methods gets the test instance as the first parameter,
+  through which you can access its fields (``test.<resource>``, ``test.config``,
+  ``test.work_dir``, etc.)
 
 * Monitors that run in the background and periodically save data or run a validation,
-    like the above suggested CPU usage monitor.
+  like the above suggested CPU usage monitor.
 
-    To create such a monitor, simply override the class field ``CYCLE`` and the
-    method ``run_monitor``.
+  To create such a monitor, simply override the class field ``CYCLE`` and the
+  method ``run_monitor``.
 
-    Again, the ``run_monitor`` method (which is called periodically after `setUp`
-    and until `tearDown`) gets the test instance as a parameter, through which
-    you can get what you need.
+  Again, the ``run_monitor`` method (which is called periodically after `setUp`
+  and until `tearDown`) gets the test instance as a parameter, through which
+  you can get what you need.
 
-    Note that the monitor thread is created only for upper tests, e.g. ``TestCases``
-    or topmost ``TestFlows``.
+  Note that the monitor thread is created only for upper tests, i.e. ``TestCases``
+  or topmost ``TestFlows``.
 
-    Remember that you might need to use some synchronization mechanism since
-    you're running in a different thread yet using the test's own resources.
+  Remember that you might need to use some synchronization mechanism since
+  you're running in a different thread yet using the test's own resources.
 
 
 Use the method ``fail_test`` to add monitor failures to your tests in the background, e.g.
@@ -76,10 +70,8 @@ Use the method ``fail_test`` to add monitor failures to your tests in the backgr
 
 Note that when using ``TestBlocks`` and ``TestFlows``, you might want to limit
 your monitor events to only be applied on main tests and not sub-components
-(``run_monitor`` already behaves that way by default).
-
-For your convenience, you can use the following decorators on the
-overridden event methods to limit their activity:
+(``run_monitor`` already behaves that way by default). For your convenience, you
+can use the following decorators on the overridden event methods to limit their activity:
 
 .. autofunction:: rotest.core.result.monitor.monitor.skip_if_case
 

docs/cli_options/client_options.rst

@@ -439,27 +439,34 @@ For example:
 
 .. code-block:: python
 
-    # utils/foo.py
+    # utils/baz.py
 
-    def add_foo_option(parser):
-        """Add the 'foo' flag to the CLI options."""
-        parser.add_argument("--foo", "-B", action="store_true",
-                        help="The amazing Foo flag")
+    def add_baz_option(parser):
+        """Add the 'baz' flag to the CLI options."""
+        parser.add_argument("--baz", "-B", action="store_true",
+                            help="The amazing Baz flag")
 
 
-    def use_foo_option(tests, config):
-        """Print the list of tests if 'foo' is on."""
-        if config.foo is True:
+    def use_baz_option(tests, config):
+        """Print the list of tests if 'baz' is on."""
+        if config.baz is True:
             print tests
 
 
-And in your ``setup.py`` file inside ``Setup()``:
+And in your ``setup.py`` file inside ``setup()``:
 
     .. code-block:: python
 
         entry_points={
             "rotest.cli_client_parsers":
-                ["foo_parser = utils.foo:add_foo_option"],
+                ["baz_parser = utils.baz:add_baz_option"],
             "rotest.cli_client_actions":
-                ["foo_func = utils.foo:use_foo_option"]
+                ["baz_func = utils.baz:use_baz_option"]
         },
+
+
+* Make sure it's being installed in the environment by calling
+
+    .. code-block:: console
+
+        python setup.py develop

src/rotest/core/__init__.py

@@ -1,7 +1,10 @@
-from .flow import TestFlow
-from .case import TestCase
-from .block import TestBlock
-from .suite import TestSuite
-from .abstract_test import request
-from .flow_component import (MODE_CRITICAL, MODE_FINALLY, MODE_OPTIONAL,
-                             PipeTo, BlockInput, BlockOutput)
+from .flow import TestFlow
+from .case import TestCase
+from .block import TestBlock
+from .suite import TestSuite
+from .abstract_test import request
+from .flow_component import (MODE_CRITICAL, MODE_FINALLY, MODE_OPTIONAL,
+                             PipeTo, BlockInput, BlockOutput)
+from .result.monitor.monitor import (AbstractMonitor, AbstractResourceMonitor,
+                                     require_attr, skip_if_case, skip_if_flow,
+                                     skip_if_block, skip_if_not_main)

src/rotest/core/result/monitor/monitor.py

@@ -2,6 +2,15 @@
 
 Implement monitors and use them as output handlers to monitor background
 processes, statuses and resources.
+
+A monitor is an output handler that uses tests' attributes, like resources.
+There are two kinds of monitors:
+1. basic monitors - react to the test's event - start, finish, error, etc.
+2. cyclic monitors - run periodically in the background during the test.
+
+To implement a cyclic monitor, override 'run_monitor' and specify 'CYCLE',
+if not implemented, the monitor will be a basic one (cyclic monitors can
+react to tests' event too).
 """
 # pylint: disable=broad-except
 from __future__ import absolute_import
@@ -89,15 +98,6 @@ def wrapped_func(self, test, *args, **kwargs):
 class AbstractMonitor(AbstractResultHandler):
     """Abstract monitor class.
 
-    A monitor is an output handler that uses tests' attributes, like resources.
-    There are two kinds of monitors:
-    1. basic monitors - react to the test's event - start, finish, error, etc.
-    2. cyclic monitors - run periodically in the background during the test.
-
-    To implement a cyclic monitor, override 'run_monitor' and specify 'CYCLE',
-    if not implemented, the monitor will be a basic one (cyclic monitors can
-    react to tests' event too).
-
     Attributes:
         CYCLE (number): sleep time in seconds between monitor runs.
         SINGLE_FAILURE (bool): whether to continue running the monitor after