Fixed static tests

Author: sivaschenko

src/contributor-guide/pull-request-tests.md

@@ -37,9 +37,9 @@ Integration Tests are PHPUnit-based tests that check the behaviour of group of M
 
 ### WebAPI Tests
 WebAPI Tests are functional tests that check the behavior of Magento Web API endpoints. They send requests to endpoints of installed Magento instance and and then check the response received and the state of the instance. Currently they include three kinds of tests:
-* SOAP Web API tests
-* REST Web API tests
-* GraphQL WEB API tests
+-  SOAP Web API tests
+-  REST Web API tests
+-  GraphQL WEB API tests
 
 ### Static Tests
 Static Tests are set of different checks that analyze each single file of Magento code base separately. Most of them analyze the whole Magento code base whereas some run only against the change set.
@@ -51,33 +51,33 @@ Database Compare is a test which compares DB schema and data between freshly ins
 ### Magento Component Health Index
 
 Magento Component Health Index is a test which analyses Magento code quality and calculates weighted health index (100 is great, lower is worse) per Magento Component (module). The index is calculated based on 3 groups of indicators:
-* General code quality indicators (GCQI). The metrics described [here](http://pdepend.org/documentation/software-metrics/index.html):
-   * Inheritance rate
-   * Coupling Between Objects
-   * Cyclomatic Complexity Number
-   * Class Size
-   * NPath Complexity
-   * Code Rank
-   * Number Of Methods
-   * Number Of Child Classes
-* Magento-specific code quality indicators (MSCQ):
-   * Inline JS usage (<script> tag without attribute **x-magento-init** or **x-magento-template**)
-   * PHP Static method calls (except unit tests)
-   * PHP global state usage (global variables usage & static local variable usage, registry object usage)
-   * PHP usage of protected modifiers for methods & properties (except unit tests)
-   * PHP and JS 'fixmeComments' usage (**TODO**, **FIXME**, **HACK**, **XXX**, **@SuppressWarnings** etc.)
-* Legacy API usage indicators (LAI):
-   * Legacy method calls in action classes (**loadLayout()**, **renderLayout()** etc.)
-   * Legacy classes extension (**\Magento\Backend\Block\Widget\Grid\Extended**, **\Magento\Backend\Block\Widget\Form**, **\Magento\Backend\Block\Widget\Form\Generic**, **\Magento\Payment\Model\Method\AbstractMethod**, **\Magento\Payment\Model\Method\Cc**, **\Magento\Backend\Block\Widget\Grid** etc.)
-   * Legacy layout block classes usage
-   * Direct class calls instead of an interface that has DI preference
-   * Comparison of composer dependencies against etalon file
+-  General code quality indicators (GCQI). The metrics described [here](http://pdepend.org/documentation/software-metrics/index.html):
+  -  Inheritance rate
+  -  Coupling Between Objects
+  -  Cyclomatic Complexity Number
+  -  Class Size
+  -  NPath Complexity
+  -  Code Rank
+  -  Number Of Methods
+  -  Number Of Child Classes
+-  Magento-specific code quality indicators (MSCQ):
+  -  Inline JS usage (<script> tag without attribute **x-magento-init** or **x-magento-template**)
+  -  PHP Static method calls (except unit tests)
+  -  PHP global state usage (global variables usage & static local variable usage, registry object usage)
+  -  PHP usage of protected modifiers for methods & properties (except unit tests)
+  -  PHP and JS 'fixmeComments' usage (**TODO**, **FIXME**, **HACK**, **XXX**, **@SuppressWarnings** etc.)
+-  Legacy API usage indicators (LAI):
+   -  Legacy method calls in action classes (**loadLayout()**, **renderLayout()** etc.)
+   -  Legacy classes extension (**\Magento\Backend\Block\Widget\Grid\Extended**, **\Magento\Backend\Block\Widget\Form**, **\Magento\Backend\Block\Widget\Form\Generic**, **\Magento\Payment\Model\Method\AbstractMethod**, **\Magento\Payment\Model\Method\Cc**, **\Magento\Backend\Block\Widget\Grid** etc.)
+   -  Legacy layout block classes usage
+   -  Direct class calls instead of an interface that has DI preference
+   -  Comparison of composer dependencies against etalon file
 
 ## Running tests for a pull request {#run-pull-request-tests}
 
 Automated tests can be triggered manually with an appropriate comment:
-- `@magento run all tests` - run or re-run all required tests against the PR changes
-- `@magento run <test-build(s)>` - run or re-run specific test build(s)
+-  `@magento run all tests` - run or re-run all required tests against the PR changes
+-  `@magento run <test-build(s)>` - run or re-run specific test build(s)
   For example: `@magento run Unit Tests` or `@magento run Unit Tests,Integration Tests`
 
 `<test-build(s)>` is a comma-separated list of build names. Allowed build names are:
@@ -107,10 +107,12 @@ When the contribution requires changes to more than one repository merged simult
 
 The related pull requests should be specified in the pull request description in the following format:
 
-    ### Related Pull Requests
-    https://github.com/<organization>/<repository>/pull/<pull request number>
-    <links to other realted PRs>
-    <!-- related pull request placeholder -->
+```
+### Related Pull Requests
+https://github.com/<organization>/<repository>/pull/<pull request number>
+<links to other realted PRs>
+<!-- related pull request placeholder -->
+```
 
 When the tests are launched against a pull request that contains links to related pull request in the description the related pull requests branches will be used as a code base for the tests instead of mainline.
 Check runs will be updated for each of the related pull requests.