From 2b63550f650c2ae412b5515cd596f38261619d27 Mon Sep 17 00:00:00 2001 From: Cédric Ollivier Date: Wed, 4 Apr 2018 06:24:12 +0200 Subject: Fix Functest Internship Reports MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It allows building these documentations via tox. rst files are now checked via doc8. Change-Id: I06096d466b672e4c171240c918d1c91e1b3dfd13 Signed-off-by: Cédric Ollivier --- .../developer/internship/unit_tests/conf.py | 185 +++++++++++++++++++++ .../developer/internship/unit_tests/index.rst | 57 +++---- 2 files changed, 212 insertions(+), 30 deletions(-) create mode 100644 docs/testing/developer/internship/unit_tests/conf.py (limited to 'docs/testing/developer/internship/unit_tests') diff --git a/docs/testing/developer/internship/unit_tests/conf.py b/docs/testing/developer/internship/unit_tests/conf.py new file mode 100644 index 000000000..7bb31d406 --- /dev/null +++ b/docs/testing/developer/internship/unit_tests/conf.py @@ -0,0 +1,185 @@ +# -*- coding: utf-8 -*- +# +# Functest Unit tests documentation build configuration file, created by +# sphinx-quickstart on Wed Apr 4 06:04:23 2018. +# +# This file is execfile()d with the current directory set to its +# containing dir. +# +# Note that not all possible configuration values are present in this +# autogenerated file. +# +# All configuration values have a default; values that are commented out +# serve to show the default. + +# If extensions (or modules to document with autodoc) are in another directory, +# add these directories to sys.path here. If the directory is relative to the +# documentation root, use os.path.abspath to make it absolute, like shown here. +# +# import os +# import sys +# sys.path.insert(0, os.path.abspath('.')) +import sphinx_opnfv_theme + + +# -- General configuration ------------------------------------------------ + +# If your documentation needs a minimal Sphinx version, state it here. +# +# needs_sphinx = '1.0' + +# Add any Sphinx extension module names here, as strings. They can be +# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom +# ones. +extensions = [] + +# Add any paths that contain templates here, relative to this directory. +templates_path = ['_templates'] + +# The suffix(es) of source filenames. +# You can specify multiple suffix as a list of string: +# +# source_suffix = ['.rst', '.md'] +source_suffix = '.rst' + +# The master toctree document. +master_doc = 'index' + +# General information about the project. +project = u'Functest Unit tests' +copyright = u'2018, Cédric Ollivier ' +author = u'Cédric Ollivier ' + +# The version info for the project you're documenting, acts as replacement for +# |version| and |release|, also used in various other places throughout the +# built documents. +# +# The short X.Y version. +version = u'master' +# The full version, including alpha/beta/rc tags. +release = u'master' + +# The language for content autogenerated by Sphinx. Refer to documentation +# for a list of supported languages. +# +# This is also used if you do content translation via gettext catalogs. +# Usually you set "language" from the command line for these cases. +language = None + +# List of patterns, relative to source directory, that match files and +# directories to ignore when looking for source files. +# This patterns also effect to html_static_path and html_extra_path +exclude_patterns = [] + +# The name of the Pygments (syntax highlighting) style to use. +pygments_style = 'sphinx' + +# If true, `todo` and `todoList` produce output, else they produce nothing. +todo_include_todos = False + + +# -- Options for HTML output ---------------------------------------------- + +# The theme to use for HTML and HTML Help pages. See the documentation for +# a list of builtin themes. +# +html_theme = 'opnfv' + +# Theme options are theme-specific and customize the look and feel of a theme +# further. For a list of options available for each theme, see the +# documentation. +# +# html_theme_options = {} +html_theme_options = { + 'bootswatch_theme': 'journal', + 'navbar_sidebarrel': False, + 'navbar_title': '', +} + +# Add any paths that contain custom themes here, relative to this directory. +# html_theme_path = [] +html_theme_path = sphinx_opnfv_theme.get_html_theme_path() + +# Add any paths that contain custom static files (such as style sheets) here, +# relative to this directory. They are copied after the builtin static files, +# so a file named "default.css" will overwrite the builtin "default.css". +# html_static_path = [] + +# Custom sidebar templates, must be a dictionary that maps document names +# to template names. +# +# This is required for the alabaster theme +# refs: http://alabaster.readthedocs.io/en/latest/installation.html#sidebars +html_sidebars = { + '**': [ + 'relations.html', # needs 'show_related': True theme option to display + 'searchbox.html', + ] +} + + +# -- Options for HTMLHelp output ------------------------------------------ + +# Output file base name for HTML help builder. +htmlhelp_basename = 'FunctestUnittestsdoc' + + +# -- Options for LaTeX output --------------------------------------------- + +latex_elements = { + # The paper size ('letterpaper' or 'a4paper'). + # + # 'papersize': 'letterpaper', + + # The font size ('10pt', '11pt' or '12pt'). + # + # 'pointsize': '10pt', + + # Additional stuff for the LaTeX preamble. + # + # 'preamble': '', + + # Latex figure (float) alignment + # + # 'figure_align': 'htbp', +} + +# Grouping the document tree into LaTeX files. List of tuples +# (source start file, target name, title, +# author, documentclass [howto, manual, or own class]). +latex_documents = [ + (master_doc, + 'FunctestUnittests.tex', + u'Functest Unit tests Documentation', + u'Cédric Ollivier \\textless{}cedric.ollivier@orange.com\\textgreater{}', + 'manual'), +] + + +# -- Options for manual page output --------------------------------------- + +# One entry per manual page. List of tuples +# (source start file, name, description, authors, manual section). +man_pages = [ + (master_doc, + 'functestunittests', + u'Functest Unit tests Documentation', + [author], + 1) +] + + +# -- Options for Texinfo output ------------------------------------------- + +# Grouping the document tree into Texinfo files. List of tuples +# (source start file, target name, title, author, +# dir menu entry, description, category) +texinfo_documents = [ + (master_doc, + 'FunctestUnittests', + u'Functest Unit tests Documentation', + author, + 'FunctestUnittests', + 'One line description of project.', + 'Miscellaneous'), +] 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 . +.. 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. -- cgit 1.2.3-korg