SWAT checklist for testing


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.


  1. isuru [at] opensource [dot] lk
  2. mahesh [at] opensource [dot] lk
  3. viraj [at] gmail [dot] com

Modules under SWAT for this week

  1. Organization Registry
  2. Request Management System
  3. Inventory Management System
  4. Catalog System

Main coding conventions

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

  • 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 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

  1. Parse the file using PHPCheckstyle and generate the violation report
  2. Identify the common coding convention violations in the file manually
  3. Submit a bug in the bug tracker attaching the violation report and the manually identified violations
  4. For each and every file of a module this process should be repeated
  5. 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

QR Code
QR Code swat:design (generated for current page)