Quality in PHP projects beyond Unittests.pdf

Quality in PHP projects beyond Unittests

International PHP Conference 2008October 30th 2008 | Thorsten Rinne

© MAYFLOWER GmbH 2008

2


Introduction

❙ Thorsten Rinne

❙ 31 years old

❙ Senior Developer and Team Lead at Mayflower GmbH

❙ Reporting applications

❙ Rating applications

❙ PHP consulting for QA and migration problems

❙ PHP software development since 1999

❙ Founder and main developer of open source FAQ management software phpMyFAQ since 2001

❙ Zend Certified Engineer (PHP 5)


3


Introduction

❙ Warm up

❙ Quality Criterias

❙ Quality Metrics

❙ Testing

❙ PHP Source Code Quality

❙ Questions and answers


4


Who are you?

❙ What's your profession?

❙ Software company or agency?

❙ What's your team size?

❙ Who develops using Unittests?

❙ Who uses QA supporting tools?

❙ What's your test coverage?

❙ Even for legacy code? :-)


5


Quality Criterias


6


Quality criterias:Understandability

❙ Availability of documentation

❙ Good documentation quality

❙ Complexity of software

❙ Code commenting and formatting

❙ Understandable naming


7


Quality criterias:Completeness

❙ Everything is already there

❙ Your application is fully implemented

❙ No mockups or temporary solutions left

❙ External interfaces are usable

❙ All needed data is available


8


Quality criterias:Conciseness

❙ No unneeded, overlong documentation

❙ Especially auto-generated documentation

❙ No unused libraries

❙ No dead code

❙ No duplicate code

❙ No code inside loops that could be outside


9


Quality criterias:Portability

❙ Easy to configure in new environments

❙ Few OS and webserver dependencies

❙ Few, documented version dependencies

❙ Language version

❙ Database version

❙ External libraries

❙ Able to survice environment updates


10


Quality criterias:Consistency

❙ Predictability

❙ Directory paths and filenames

❙ Class and method names

❙ Variable and constant names

❙ Documentation style and language

❙ Coding style


11


Quality criterias:Maintainability

❙ Easy to install and easy to upgrade

❙ Tests and debug logs to help to locate bugs

❙ Few dependencies hiding the bug

❙ No complex dependencies or effects on the platform

❙ Easy to understand and navigate source code


12


Quality criterias:Testability

❙ Known acceptence criteria

❙ Adequate separation of concerns

❙ Easy to use interfaces for tests

❙ No limiting dependencies


13


Quality criterias:Reliability

❙ The criteria formerly known as „robustness“

❙ Fault tolerance

❙ Graceful degradation

❙ Exception handling exists

❙ Is method input checked?


14


Quality criterias:Usability

❙ Learnability: Easyness of first time usage

❙ Efficiency: Overall speed of usage per task

❙ Memorabilty: Time to re-establish usage knowledge after absence

❙ Errors: Frequency of usage errors

❙ Satisfaction: Fun to use the software


15


Quality Metrics


16


Quality Metrics:Defect Density Metrics

❙ Code-based metric

❙ Defects per KSSI (1000 shipped source instructions) for product quality

❙ Defects per KCSI (1000 changed source instructions) for development quality

❙ (Hard to measure)

❙ Statistic needed

❙ easier for products


17


Quality Metrics:Customer Problem Metrics

❙ PUM: Problems per user month

❙ Defects per month / number of installations

❙ Maintainance metric: Number of bugs closed / number of bugs arrived

❙ The customer does not care how big or how complicated the software is :-)


18


Quality Metrics:Customer Satisfaction Metrics

❙ You only get them by survey

❙ for

❙ Functionality

❙ Usability

❙ Reliability

❙ Performance

❙ Maintainability

❙ Service

❙ Levels: Very Satisfied, Satisfied, Neutral, Dissatisfied, Very Dissatisfied


19


Quality Metrics:When are bugs detected?

❙ Number of pre-release bugs found while testing

❙ Number of post-release bugs

❙ found by customer

❙ found by testing


20


Quality Metrics:How are defects fixed?

❙ Average Time to fix a bug

❙ Average Time for bugfix release

❙ that‘s the time relevant for the customer

❙ Average engineering hours / fixed defect


21


Quality Metrics:Defect Impact

❙ was the defect visible to the user?

❙ has a monetary transaction been touched?

❙ has sensitive data been touched?

❙ are there security implications?

❙ has there been a marketing/image effect

❙ did data / user work get lost?


22


Quality Metrics:Testing Efficiency

❙ Found bugs before release / found bugs post release

❙ Found bugs by qa team / found bugs by customer

❙ Number of bugs found by QA Team / time


23


„We do PHPUnit!“ !== Testing


24


Unit Testing

❙ For PHP: PHPUnit or SimpleTest

❙ Focussing on testing a single unit of work

❙ solves depencies using mock objects

❙ should not depend on database

❙ perfect and easy to automate

❙ Reason for all refactoring


25


Acceptence Testing

❙ originally user acceptance testing❙ one of the final testing stages

❙ change to automated black box testing in agile environments

❙ used to test user stories❙ often contractual requirement


26


SOA / Service Testing

❙ in multi-tier environments every service can have several consumers

❙ black box test for the service api

❙ can easily be automated

❙ a lot of tools for SOAP


27


Integration Testing

❙ tests the application with all parts

❙ needed for multi-tier applications

❙ tests the interaction paths

❙ intersection with load testing: user simulation


28


Load Testing

❙ Simulates high load situations

❙ to detect the current platform abilities

❙ to detect resource bottlenecks (Database, CPU, Network)

❙ to detect concurreny bottlenecks (locking jams, caching effects)

❙ Scalability testing: scale up or scale out?


29


Usability Testing

❙ How does the user work with the application?

❙ Efficiency: time to fulfill a basic task

❙ Accuracy: how many mistakes happened?

❙ Recall: does the user recall the usage after a period of time?

❙ Emotional response: does the user feel lucky, confident or stressed about the task?


30


Regression Testing

❙ originally: if you find a bug, fix it and write a test

❙ PHP itself does it

❙ now often written by the test team to assure the expected default behavior

❙ modern: automated test generation


31


Security Testing

❙ Blackbox: Penetration Test done by external auditor just before release

❙ Graybox: using tools like fuzzers and scanners before release or while development

❙ Whitebox: internal or external source code audit, static code analysis while development


32


A lot more ...

❙ Compability testing for maintainability

❙ Volume testing for bigger amounts of data

❙ Stress testing for degrade and failover processes

❙ Installation testing for maintenance

❙ Recovery testing to check recovery behavior


33


PHP Source Code Quality


34


Documentation

❙ We have different forms of documentation:

❙ Inline documentation

❙ API documentation

❙ Developer documentation

❙ Security documentation

❙ Administration documentation

❙ End-user documentation


35


Coding Style / Formatting

❙ Coding style is defined in the developer documentation

❙ All developers have to write their code formatted in the given coding style

❙ Can be checked by CodeSniffer tools

❙ Coding style should be based on your main used libraries

❙ If you build your application on top of the Zend Framework, use the ZF coding style

❙ With IDEs like Eclipse you can format old code autpmatically


36


Naming Conventions

❙ Naming conventions are very important❙ No\namespaces\before\PHP\5.3❙ Easier for __autoload()

❙ Examples❙ Class names:

❙ class HTML_Template_ITX2❙ Directory: include/PEAR2/HTML/Template/ITX2.php

❙ Function names in camel caps:❙ public function blockExists($blockname)


37


Code Complexity

❙ Complexity costs time and money if you don‘t need it

❙ KISS principle: Keep it simple and stupid

❙ Complexity checks by CodeSniffer metrics

❙ Important for good code coverage and unittests

❙ Examples

❙ Too high number of linearly independent paths through a program's source code

❙ Too long class and method names

❙ Too many properties

❙ Too many parameters

❙ Too many methods inside a class


38


Anti Patterns

❙ An antipattern is a design pattern that appears obvious but is ineffective or far from optimal in practice

❙ Examples

❙ Unnecessary abstraction

❙ God objects

❙ Spaghetti code

❙ Too short or too long variable names


39


Anti Pattern Examples

❙ if(<EXPR>) {<empty>}❙ if(<EXPR>) {<EXPR>} else {<empty>}❙ try(<EXPR>) {<empty>}❙ try(<EXPR>) {<EXPR>} catch(Exception $e) {<empty>}

❙ define('SOME_NAME', $var)❙ include[_once]|require[_once]|readfile|virtual|file_get_contents|fopen|file|mysql_query($_GET|$_POST|$_REQUEST)


40


Questions?

Thank you very much!

Thorsten RinneMayflower GmbH

Mannhardtstr. 6 80538 München+49 (89) 24 20 54 - [email protected]

Technology

Quality in PHP projects beyond Unittests.pdf