X-Git-Url: https://gerrit.opnfv.org/gerrit/gitweb?a=blobdiff_plain;f=docs%2Ftesting%2Fdeveloper%2Finternship%2Funit_tests%2Findex.rst;h=f79e9e2968aa92d9e8fcde9a85e4882b10ccff96;hb=d0d471502ff7b5dfabf4a2ede79782c5708a463c;hp=a117c8609120e21102090b20460b2166b9c4c807;hpb=f5c8f9dd175e462bf362b5c301205a3376a0d82b;p=functest.git 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.