Table of Contents
SWAT checklist for testing
Objectives
The major objective of this process is to improve the quality of the code available in the repository ensuring all the conventions are met as in the following url. http://wiki.sahana.lk/doku.php?id=dev:php_coding_convention.Further special attention will be given to the file structure of each and every module and the folder structure of the system.All the unnecessary 3rd party libraries are expected to be cleared while necessary updated versions of the libraries are remaining during the SWAT process.
Team
- isuru [at] opensource [dot] lk
- mahesh [at] opensource [dot] lk
- viraj [at] gmail [dot] com
Modules under SWAT for this week
- Organization Registry
- Request Management System
- Inventory Management System
- Catalog System
Main coding conventions
- Assigned modules per week will be validated against the PHP coding conventions available at http://www.sahana.lk/wiki/doku.php?id=dev:php_coding_convention .
Following tests will be done using PHPCheckstyle(http://developer.spikesource.com/projects/phpcheckstyle)
- Test “noShortPhpCodeTag”: Tests and reports and error if a short php
code open tag is used.
- Test “noShellComments”: Tests and reports and error if there is a
shell/perl style comment (that starts with '#').
- Test “lineLength”: Tests for long lines and reports error if a
line exceeds the value of “maxLineLength” property. The default value of “maxLineLength” is 80.
- Test “docBlocks”: Tests that every function and class is
immediately preceded by a docblock. A property “excludePrivateMembers” can be set if you want to disable docblocks for private member functions.
- Test “controlStructNeedCurly”: Tests to make sure that every
control structure is included within a {} block, even if it is syntactically optional.
- Test “controlStructOpenCurly”: Tests for the location of the open
curly bracket for a control structure.
- Test “funcDefinitionOpenCurly”: This is similar to “controlStructOpenCurly” explained above. Except that this is for
function definition and the default value of “position” is new line (“nl”).
The other convention validations will be done manually
PHPCheckstyle installation and generate test reports
- Download phpcheckstyle from http://developer.spikesource.com/projects/phpcheckstyle
- Unzip the content to a folder i.e:phpcheckstyle
- Comment the following lines in the pear.cfg.xml file in config directory
<test name="spaceAfterControlStmt"/> <test name="spaceAfterSemicolon"/> <test name="funcDefinitionOpenCurly"> <property name="position" value="nl"/> </test> <test name="whiteSpaceSurroundsOperators"/>
- Issue the following command from the checkstyle home directory to generate the test report
php run.php –src 'PATHTOINCFILE'
- Open the generated HTML file using Firefox
Steps to validate a file against the convention
- Parse the file using PHPCheckstyle and generate the violation report
- Identify the common coding convention violations in the file manually
- Submit a bug in the bug tracker attaching the violation report and the manually identified violations
- For each and every file of a module this process should be repeated
- Developers are also expected to use PHPCheckstyle and validate their code before they mark the bug 'pending'
Module developer/designer conventions
- Reusing libraries
Developer must use the existing reusable libraries.i.e paging,localization,etc… in their modules.
- Folder structure
In each and every module 'inst' folder is expected to store all the module specific and database related files.
- File structure
Under inst folder mysql-dbcreate.sql,mysql-config.sql and sample-data.sql files are expected to be stored.
- Adhering to front controller
All the requests to the server should be navigated according to the front controller design pattern
Integration testing
- Identify module dependencies
Request Management System,Inventory Management system and Catalog system are expected to have a strong integration.In a practical situation none of the module can be deployed without the support of other modules.So a tight integration of these modules are expected and more time should be spent to identify the dependencies
Major Integration issues
- Integrate the Request Management System with the security framework
Any user should log in to the system as a general user and register as a requester or pledger.
- All the requests and pledges should be coupled with the inventory management system
- Validate the dependencies in the code