Test Driven Development and Automation


Published on

"All code is guilty until proven innocence”

Published in: Technology
1 Comment
  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Test Driven Development and Automation

  1. 1. Test Driven Development & Automation (PHP) “All code is guilty until proven innocence”
  2. 2. Things to cover• What is TDD?• Why should we do TDD?• Where should we run Tests to make sure everything is working fine?• Who should adopt TDD?• Why Unit Testing, Code coverage, code sniffer and Selenium are important?• Tools for PHP Test Driven Development.• How we automated tests with every build generation?• Quick Demo and QA.
  3. 3. What is TDD?• TDD is a programming technique that requires you to write actual code and automated test code simultaneously. This ensures that you test your code—and enables you to retest your code quickly and easily, since it’s automated.• All code is guilty until proven innocence
  4. 4. TDD• TDD is an agile development technique practice which combines Refactoring and Test-First Development.• Becks concept of test-driven development centers on two basic rules: - Never write a single line of code unless you have a failing automated test. - Eliminate duplication.
  5. 5. Why we should do TDD?“I don’t want to test because:”•As a Developer I feel lazy to test everythingagain and again. Oops!•I wanted to release my product as soon aspossible to make it available to stake holders.•I feel it’s a waste of time for me.•I prefer manual testing (Black Box Testing), justto save myself.
  6. 6. Why we should do TDD…• TDD allows us to make changes and test quickly and efficiently.• To release the product as soon as possible to make it available to stake holders without bugs.• To Reduce Product release life cycle.• To make sure product is working as expected without any bugs that we are aware of.• To make sure that end customers are getting good quality and a mature product.• To avoid silly mistakes.
  7. 7. Where should we run Tests to make sure everything is working fine?• Each developer should setup an environment to make sure that his code gets tested with every compilation or he can test cases anytime.• Integrate Unit Testing, Code Coverage and Code Sniffer with IDE to make sure your code is innocent and well written.
  8. 8. Make it automated on server side.• Setup test server to do all the demo installation and testing stuff.• Package your code.• Create Self installation script.• Run installation with Unit Test Cases.• Check Code coverage and Sniff your code.• Run PHP Selenium test cases to test your UI.• Generate Public Build if your code passes all the tests.• If test cases fail then do not generate build and raise RED Signal to developers.
  9. 9. Who should adopt to TDD?• Every one, Either it’s a product development company or Services based company. “Management support is essential. Without the entire organization believing that test-driven development is going to improve the product, management may feel that time spent writing tests is wasted.”• Set Strict code and testing standards if you really want painless deployment.
  10. 10. Why Unit Testing, Code coverage, code sniffer and Selenium are important?• Unit Tests check Code level test cases for Classes and functions with defined assertions.• Code Coverage ensures that you covered whole code in test cases.• Code Sniffer makes sure that you follow strict coding standards.• Selenium Tests make sure that your UI is working as expected.Above things ensures that you are going to deliver 100% working and a Quality Product.
  11. 11. Tools for PHP Test Driven Development.• Xdebug (Code Coverage)• PHPUnit• Selenium (PHPUnit_Selenium)• PHP_CodeSniffer• PHPUnderControl• IDEs with integrated TDD: – NetBeans – ZendStudio – PHPStorm
  12. 12. How to write test cases?• Fail To WIN “First fail the test cases. The idea is to ensure that the test really works and can catch an error. Once this is shown, the underlying functionality can be implemented. This has been coined the "test-driven development mantra", known as red/green/refactor where red means fail and green is pass.”• Answer your test by writing code.• Refactor and Refine your code.• Rinse and Repeat.Source: http://net.tutsplus.com/
  13. 13. Why we needed TDD for our Organization• Big Question on Big Code Base. – More than 1500 PHP Files. – More than 5 Lac lines of code. – More than 15 Developers working on same codebase with their different coding styles. – More than 300 integrated features. – Multiple channels of data communication (XML based Chat, VoIP, Emails, Database queries, REST APIs, Session Based APIs) “Everything is Hard to test on every release cycle. We always miss and our customers come back to us which makes us feel bad.”• We are still struggling to convince everyone to write test cases and make our builds based on 100% TDD.
  14. 14. How we automated tests with every build generation?• Build System Integration with GitHub.• Unit Test Server with: – Auto Product Installation. – PHPUnit for all test cases. – Code Coverage check in IDE only (Not Strict on this yet) – Code Quality Check using Code Sniffer (Less errors due to good IDE and same coding templates and standards) – Next Step we are planning to add Selenium (Already done with test deployments) – Then we deploy on our own live installation and tell our team to keep eyes on any error or exceptions. If everything goes perfectly fine then release builds. Else send error messages in Internal Jabber bases IM clients and via email. It’s a complete test eco system to make sure we provide a quality product. This is how we deploy our product to more than 30k customers including automated SaaS upgrade system.
  15. 15. Code to fail
  16. 16. Failure Output in NetBeans
  17. 17. Correct Code
  18. 18. Success Output with Code Coverage
  19. 19. Unreadable code with silly mistakes
  20. 20. Well written code
  21. 21. Code Sniffer
  22. 22. Code Sniffer…
  23. 23. Our Final Build Status
  24. 24. Our Final Build Logs
  25. 25. Insane programmer who do not tests code. Source: http://www.kavistechnology.com/
  26. 26. Super-Duper Programmer who tests his code
  27. 27. Thank You Mahesh Salariamahesh.salaria@kayako.com http://twitter.com/salaria