Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
swat:design [2007/09/24 09:35]
isuru
swat:design [2009/07/06 20:36] (current)
Line 1: Line 1:
-**SWAT checklist for Testing**+**SWAT checklist for testing**
  
-**1.Code 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.   
-        *PHPCheckstyle(http://developer.spikesource.com/projects/phpcheckstyle)  validation       
-    
  
-**2.Module Developer Conventions**+ 
 + 
 + 
 + 
 + 
 +__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          *Reusing libraries
 +Developer must use the existing reusable libraries.i.e paging,localization,etc... in their modules.     
          *Folder structure          *Folder structure
 +In each and every module 'inst' folder is expected to store all the module specific and database related files. 
          *File structure          *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          *Adhering to front controller
-      +All the requests to the server should be navigated according to the front controller design pattern      
-**3.Integration testing**  + 
-         *Module dependency issues + 
-          + 
 + 
 + 
 +===== 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
  
  
  

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