Successfully reported this slideshow.

Software Testing Concepts


Published on

Focusing on PHPUnit, PHP_CodeCoverage, and xDebug

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Software Testing Concepts

  1. 1. SOFTWARE TESTING CONCEPTS With a focus on PHPUnit, PHP_CodeCoverage, and xDebug
  2. 2. INTRODUCTION Aaron Bernstein – Aspiring Engineer  One of the lead software engineers in the Workspace Team at GoDaddy  Been working with GoDaddy for about a year and a half.  Specifically tasked on our FaxThruEmail product. Micah Wood – Aspiring Software Engineer  One of the software engineers in the Workspace Team at GoDaddy  Been working with GoDaddy for about four years.  Specifically tasked on our FaxThruEmail product. Farhan Zaman – Software Engineer in Test  One of the automation engineers in the Workspace Team at GoDaddy  Been working with GoDaddy for about three and a half.  Specifically tasked on our Email Infrastructure and AIR product. Combined Experience Includes:  Fifteen plus years of programming in a multitude of languages…  We’ve all been working towards fully covering our applications with unit, functional, integration, and browser testing over time.
  3. 3. WHO You, should love testing!!
  4. 4. ROLES Software Engineers Throughout the development process, one should be performing tests on code that they author. Test Engineers By the nature of the title, their primary function is to test software. Automation Engineers Developing tools and procedures to test software through automated methods. Management Ultimately responsible for the product integrity.
  5. 5. WHAT Anything you code!!
  6. 6. LEVELS AND TYPES OF SOFTWARE TESTING LEVELS TYPES • Unit • A/B • System • Internationalization and localization • Acceptance • Acceptance • Installation • Accessibility • Functional/Non-Functional • Alpha/Beta • Regression • Integration • Compatibility • Destructive • Development • Smoke and Sanity • Software Performance • Security • Usability
  7. 7. TESTING METHODS STATIC DYNAMIC Reviews, walkthroughs, or inspections are referred to as static testing. Executing programmed code with a given set of test cases is referred to as dynamic testing. Static testing can be omitted, and in practice often is. Dynamic testing takes place when the program itself is used. Dynamic testing may begin before the program is 100% complete in order to test particular sections of code and are applied to discrete functions or modules. Typical techniques for this are either using stubs/drivers or execution from a debugger environment.
  8. 8. WHEN As much as feasibly possible!!
  9. 9. PARTS OF THE PROOFING PROCESS VERIFICATION VALIDATION The process of determining whether the products of a given phase of the software development process fulfill the requirements established during the previous phase. The process of evaluating software at the end of software development to ensure compliance with intended usage.
  10. 10. WHERE But of course, where it fits!!
  11. 11. CONTINUOUS INTEGRATION AND/OR TRIGGERS THROUGH CONTINUOUS INTEGRATION METHODS • Repository • Polling • Package Management • At build time • Deployments • At deployment time • SCM Hooks • Client-Side • This section splits them into committing workflow hooks, e-mail workflow scripts, and the rest of the client-side scripts. • Server-Side • These scripts run before and after pushes to the server. * all of which can be quantified and automated.
  12. 12. WHY Even the best programmers, can and do, make mistakes!!
  13. 13. COST OF NOT TESTING OR LATE TESTING Testing is the most time consuming and expensive part of software development. Not testing is even more expensive. If we have too little testing effort early, the cost of testing increases exponentially. Planning for testing after development is prohibitively expensive. MAIN FUNCTIONS OF TESTING • Improve quality • Reduce cost • Preserve customer satisfaction
  14. 14. HOW Bunch of sugar and spice!! (Magic and Fairy Dust)
  15. 15. CODE QUALITY AND THE C.R.A.P. INDEX The C.R.A.P. (Change Risk Analysis and Predictions) index is designed to analyze and predict the amount of effort, pain, and time required to maintain an existing body of code. The other factor used in calculating the C.R.A.P index, is the number of logic “paths” found within the code.  The more individual paths found, the harder the code is to maintain and the higher the index will be. Given a Java method m,  C.R.A.P.(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) 90% of everything is crap. ~Sturgeon’s Law (one of many variants) …software metrics, in general, are just tools. No single metric can tell the whole story; it’s just one more data point. Metrics are meant to be used by developers, not the other way around – the metric should work for you, you should not have to work for the metric. Metrics should never be an end unto themselves. Metrics are meant to help you think, not to do the thinking for you. ~Alberto Savoia
  16. 16. TOOLS PHPUnit, PHP_CodeCoverage, and xDebug
  17. 17. PHPUNIT Testing with PHPUnit is not a totally different activity from what you should already be doing. It is just a different way of doing it. The difference is between testing: • Checking that your program behaves as expected, • Performing a battery of tests, runnable codefragments that automatically test the correctness of parts (units) of the software. These runnable code-fragments are called unit tests. Current Requirements PHPUnit 3.7 requires PHP 5.3.3 (or later), but PHP 5.5.1 (or later) is highly recommended. PHP_CodeCoverage, the library that is used by PHPUnit to collect and process code coverage information, depends on Xdebug 2.0.5 (or later), but Xdebug 2.2.3 (or later) is highly recommended.
  18. 18. PHPUNIT TESTING Demonstration
  19. 19. THANK YOU! QUESTIONS? RESOURCES CONTACT INFORMATION Software Testing Provide feel free to contact us at the following addresses. PHPUnit xDebug Clover PHP Plugin for Jenkins Clover Documentation Pardon My French, But This Code is C.R.A.P. (1) (2) How to Read and Improve the C.R.A.P. Index of Your Code m: gd_github: abernstein twitter: @bernstein_aaron m: gd_github: fzaman twitter: @farhan_zaman m: gd_github: mwood