Transcript common development and testing tools Jon Daniel Colin Dean 7 October, 2009 "Programming is managing forgetfulness." Paul Oehler CTO of InterWorx, LLC.

common development and
testing tools
Jon Daniel
Colin Dean
7 October, 2009
"Programming is managing forgetfulness."
Paul Oehler
CTO of InterWorx, LLC
tools every programmer should use
• Version Control
• Code Sniffing
• Code Testing
o Unit Testing
o Functional Testing
o Acceptance Testing
o Regression Testing
o Interface (UI) Testing
o Continuous Integration
version control
•
•
•
•
•
•
Used to store "snapshots" of your codebase
Allow you to create different "branches" of code
Makes merging and identifying changes easy
Helps manage forgetfulness
Can be either centralized or distributed (or a hybrid)
Many different open source packages available
popular version control systems
• Open Source
o CVS (Concurrent Versions System)
o Subversion
o Git
o Bazaar
o SVK
o DARCS
o Mercurial (hg)
• Commercial
o BitKeeper
o Perforce
o MS Visual SourceSafe
Centralized VCS
Distributed VCS
centralized versus distributed
•
•
•
•
•
Central management
One repository
Simpler tools
Smaller workflow
Single point of failure
o Ask Jon about rm trunk
o Revision history is gold
• Older systems integrated
• Branches for version work
• Tags for releases
• Many copies of history
o Larger local repo
o All history can be local
• Commit then push
• Can be centralized
o Bazaar does this (LP)
o Git kinda does this
• Every bug fix is a branch
• Branches for versions
• Branches for releases
http://en.wikipedia.org/wiki/Distributed_revision_control
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
PHP_CodeSniffer
• Works with CSS, JavaScript, and PHP files
• Is used to detect coding style violations
• Can be configured to meet your needs
o Includes templates for coding standards such as Zend
and PEAR
• Can be used in conjunction with version control
JSLint
• Developed by Douglas Crockford
o Author of many JavaScript books you know and love
• Finds common problems in JavaScript code
• Yells at you when it thinks you do something stupid
test-driven development
Widget
• Write functionality as tests
• One test per method
o Or method set
• Write code to pass test
o Try not to modify test
• New code = new test
create()
destroy()
render()
airspeedVelocity()
Widget_Test
test_create()
test_destroy()
test_render()
test_airspeedVelocity()
Software Testing
It's not the the QA department's job!
unit testing
• Unit = smallest testable section of code
• do_something_small() NOT do_everything()
• One test to one class
o Class should generally be a model in MVC paradigm
o Not a militant restriction
• Failed test pinpoints problem code
• Setup/teardown
• Stubs, mockups, fakes
• Modular testing
o Tests NEVER rely on another test for anything
• Living documentation
• Code examples
http://en.wikipedia.org/wiki/Unit_testing
functional testing
• "Does this action cause a desired state?"
• Glue stage between Unit and Acceptance testing
o Tests larger units than Unit tests
o More opaque than Acceptance tests
• Tests unit interaction
o Controller tests in MVC
o Controller+View tests in loose MVC
• Tests multiple units simultaneously
• Not always run continuously
o May require more resources
o This is but a small hurdle--jump it and move on
acceptance testing
•
•
•
•
Also known as "Black Box" testing
Given certain inputs, certain outputs are received
Does not look at the inner workings of the module
Concerned with high level application testing
o Generally "shallow and wide"
o Touching all areas is most important
http://en.wikipedia.org/wiki/Acceptance_testing
regression testing
• Detects regression
o Reappearances of bugs
o Decreased performance
• Identifies faults before QA
• One regression test per bug
Excellent example: Automated tests when compiling PHP
""regression testing"? What's that? If it compiles, it is good, if it
boots up it is perfect." - LBT
http://en.wikipedia.org/wiki/Regression_testing
continuous integration
• Practices to decrease development and integration times
o Use source control
o Automate the build
o Builds should automatically test themselves
o Commit often and test every build
o Keep the build fast
o Test in a clone of production environment
o Alert developers of build results
http://en.wikipedia.org/wiki/Continuous_Integration
automate the build
• Going from source to application should be simple and easy
• Less relevant in PHP, but used for tasks such as
o copying code from source to testing
o reverting databases to original state
o updating config files
o setting/fixing file permissions
o running quick tests to ensure basic functionality
commit often and test every build
•
•
•
•
Never go more than a few days without a commit
Every commit to trunk (or quick set of commits) gets built
Branches should be tested, but this is less important
Never ignore a failing build
everyone gets builds results
• All developers should be given e-mails of build results
• Developers will know quickly if their code has issues
• Alert the developer if a commit of theirs has broken the build
o You can alert all developers if you are evil
continuous integration tools
• Many tools are available
o CruiseControl with PHPUnderControl is common
• Provide automated building as well as other statistics
o Build times
o Manage types of builds (full, UI, quick, "on-the-fly")
o Percentage of successfully builds
o Test coverage
interface (ui) testing
• In web development, generally a tool that runs tests through
a number of web browsers
• Ensures that interactions remain constant and the correct
information is displayed
• A useful method of "black box" testing
selenium remote control
• Useful for testing AJAX operations in your application
• Works with Firefox, Safari, Opera, and IE
• Includes a Firefox Addon to record macros and generate the
corresponding code
• Includes libraries for Java, Perl, PHP, Python, Ruby, .NET
• Can use Selenium Grid to "cluster" your tests among many
Operating Systems and browsers
getting started with unit-testing
• Starting with 0 tests can be scary
o Write simple acceptance tests
o Write a test for every new feature
o Test parts of the code you are sure work
o Test parts of code that are used the most
o Automate testing from day 1
o Strive to have 1% coverage on all classes to start
• Change practices to include test-driven development
• Test security related areas
• Look into test scaffolding scripts
o Automatically construct and destruct classes
The End!