Fix Functest Internship Reports

It allows building these documentations via tox.
rst files are now checked via doc8.

Change-Id: I06096d466b672e4c171240c918d1c91e1b3dfd13
Signed-off-by: Cédric Ollivier <cedric.ollivier@orange.com>
(cherry picked from commit 2b63550f650c2ae412b5515cd596f38261619d27)

1 files changed, 27 insertions, 30 deletions

diff --git a/docs/testing/developer/internship/unit_tests/index.rst b/docs/testing/developer/internship/unit_tests/index.rst
index a117c8609..f79e9e296 100644
--- a/docs/testing/developer/internship/unit_tests/index.rst
+++ b/docs/testing/developer/internship/unit_tests/index.rst
@@ -1,11 +1,4 @@
-=======
-License
-=======
-
-Functest Docs are licensed under a Creative Commons Attribution 4.0
-International License.
-You should have received a copy of the license along with this.
-If not, see <http://creativecommons.org/licenses/by/4.0/>.
+.. SPDX-License-Identifier: CC-BY-4.0
 
 ===================
 Functest Unit tests
@@ -36,39 +29,43 @@ Version history
 Overview:
 =========
 Functest project is developing and integrating functional test cases for OPNFV
-and it is part of OPNFV since the beginning. Functest develops its own testcases
-and framework. This framework includes several utility libraries. The Project is
-growing rapidly with more features, tests added as per requirement. It becomes
-the responsibility of every developer to maintain the integrity of code i.e. new
-patch should not break the previous functionality of the project. To automate this
-process of software development, we should write unit tests and add them to CI so
-that when a new patch is ready to merge, we shouldn't allow those which are breaking
-previous unit tests or decreasing the coverage.
+and it is part of OPNFV since the beginning. Functest develops its own
+testcases and framework. This framework includes several utility libraries. The
+Project is growing rapidly with more features, tests added as per requirement.
+It becomes the responsibility of every developer to maintain the integrity of
+code i.e. new patch should not break the previous functionality of the project.
+To automate this process of software development, we should write unit tests
+and add them to CI so that when a new patch is ready to merge, we shouldn't
+allow those which are breaking previous unit tests or decreasing the coverage.
 
 
 
 Problem Statement:
 ------------------
-The goal of the intership consists in creating unit test suites on Functest code
-with good code coverage (>80%) and integrate it in continuous integration in order
-to consolidate existing code.
+The goal of the intership consists in creating unit test suites on Functest
+code with good code coverage (>80%) and integrate it in continuous integration
+in order to consolidate existing code.
 
 
 Curation Phase
 --------------
-The curation phase was the first 3 to 4 weeks of the internship. This phase was to get
-familiar with the functest code and functionality and explore the solutions for unit
-testing in other projects and come up with the strategy for writing unit tests in functest.
+The curation phase was the first 3 to 4 weeks of the internship. This phase was
+to get familiar with the functest code and functionality and explore the
+solutions for unit testing in other projects and come up with the strategy for
+writing unit tests in functest.
 
 In this phase we decided,
-- Coverage should be 80%. There are some functions like __init__, getter, setter and other
-  private methods for which writing unit test is a tedious job, so we are leaving these methods
-  for now.
-- Do method wise testing for every module.
-- Use mock for external or third party services, system calls and other external library calls
-  which could impact the behaviour of system during the run of unit test.
-- Add it in jenkins as passing criteria for patches.
-- Write tests in modular way so that it can help to serve as a form of documentation.
+
+  - Coverage should be 80%. There are some functions like __init__, getter,
+    setter and other private methods for which writing unit test is a tedious
+    job, so we are leaving these methods for now.
+  - Do method wise testing for every module.
+  - Use mock for external or third party services, system calls and other
+    external library calls which could impact the behaviour of system during the
+    run of unit test.
+  - Add it in jenkins as passing criteria for patches.
+  - Write tests in modular way so that it can help to serve as a form of
+    documentation.