| | 1 | = Proposal: Quality Assurance workflow for BOINC = |
| | 2 | == Motivation == |
| | 3 | To increase the quality and stability of all BOINC components it is useful to run automated tests and validation tools on a regular basis. This way one can quickly see if a specific change breaks another component/part of the system or introduces a possible security risk. Overall this should help to identify weak spots in the BOINC source code. Using codesniffers (like the PHP !CodeSniffer) could help enforcing the BOINC coding guidelines. This has the side-effect of a syntax check and can also generate !ToDo/Wish lists from comments in the code. |
| | 4 | |
| | 5 | == Requirements == |
| | 6 | This is a first shot and open for discussion: |
| | 7 | |
| | 8 | * automated system that runs every night |
| | 9 | * automatically run unit tests that are in VCS |
| | 10 | * automatically run third-party tools on portions of the codebase (e.g. cppcheck, doxygen) |
| | 11 | * compile a report of the automated runs (shown via web) |
| | 12 | * support multiple nodes to test on different operating systems |
| | 13 | * support multiple git branches (e.g. run the same tests on master as on client_release/7/7.2) |
| | 14 | * support testing multiple language on portions of the VCS (C++, PHP, Java) |
| | 15 | |
| | 16 | == Tools == |
| | 17 | [http://jenkins-ci.org/ Jenkins] is a continuous integration server that is extended using plugins: |
| | 18 | * already supports JUnit and javadoc |
| | 19 | * supports git via the [https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin git plugin] |
| | 20 | * the [https://wiki.jenkins-ci.org/display/JENKINS/xUnit+Plugin xUnit plugin] can show reports from JUnit, PHPUnit and !CppUnit test tools |
| | 21 | * there is also a [https://wiki.jenkins-ci.org/display/JENKINS/Cppcheck+Plugin cppcheck plugin] |
| | 22 | Those plugins only compile a report from each of those tools. The tools need to be installed and configured separately. |
| | 23 | |
| | 24 | Using JUnit, PHPUnit and !CppUnit should simplify the creation and maintenance of test cases. |
| | 25 | |
| | 26 | Jenkins support distributed workers as build nodes. |
| | 27 | |
| | 28 | === problems === |
| | 29 | * Jenkins has no built-in user authentication |
| | 30 | * How does Jenkins handle multi-language code bases? |
| | 31 | |
| | 32 | === links === |
| | 33 | * [https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+and+PHP Jenkins and PHP] |
| | 34 | * [https://wiki.jenkins-ci.org/display/JENKINS/Terminology Jenkins Terminology] |
| | 35 | |
| | 36 | == Workflow == |
| | 37 | |
| | 38 | == On creating test cases == |
| | 39 | To create a test case one has to know what the function/class/component is supposed to do. Especially for white box tests this is crucial. Documenting the preconditions, postconditions and invariants of functions and classes is important. The documentation should be unified in regard to the used languages (C++, PHP, Java) and the used documentation tool (doxygen). It should be possible to distinguish between public and internal APIs. |
