For web applications you often need the ability to deploy new features continuously while making sure that all parts of your application still work correctly. Establishing an Continuous Integration process using an automated test suite can support you to meet those needs. This presentation tries to give an overview how this integration process can be established for Symfony2 applications and which types of tests apply. The presentation was held on the Symfony User Group Berlin on 10 Okt. 2012

1. Regression Testing with Symfony
Tools and techniques for building your test suite

2. Introducing the speaker
Joachim Unger
@joeywannabe
Symfony Explorer since 2.0
Web Developer since 2010
Former scientist at ABB Robotics
Software Developer @LittleBird GmbH
Berlin

3. Part 1: Exploring the techiques
 Regression Testing
 Test granularities in web projects
 Basic design patterns
 Symfony test components
 Behaviour Driven Development
 Continuous Integration
 Lessons learned

4. Regression Tests
 Discover new software bugs (regression)
 Verify bugfixes on existing functionality
 Validate changes against other components
 Include rerunning previously run tests
 Run on each code change
 Ensure product quality
 Minimize risks

5. Types of Regression Tests
 Progressive Regression Tests
 Specification has changed
 Code has been changed
> Add new test cases
 Correcting Regression Tests
 Specification has not changed
 Test code changes against existing test cases

6. Regression Tests in web projects
 Defined test strategy
 Test-Driven Programming
 Tests for all code changes (e.g. bugfixes)
 Tests have to be up-to-date
 Continuous Refactoring
 Automated Test Suite
 Run on each code change
 Smoke, Acceptance and Unit Tests
 Continuous Integration

7. Software Quality
 Functional Quality
 Error-free execution of application
 Strongly influences user acceptance
Browser
 Structural Quality
Controller View  Design and structure of code
Utility  Loose coupling of components
 Ensures extensibility of code
Model
ORM/DBAL

8. Unit Tests
Assert that the result of
foobar(“foo“) is “bar“.
 Verify functionality of single component
 Allow safe refactoring of code parts
 Must run successfully on each change
 Test is written with/before code

9. Acceptance Tests
Check that a click on button
„Put on shopping cart“ puts the item
into the shopping cart
 Verify the functional requirements
 Ensure the overall application usability
 Test specification provided by stakeholder

10. Smoke Tests
Check that the url of a product page
is really showing a product page
 Verify the overall application functionality
 Good to identify crucial bugs

11. Separation Of Concerns
 Separation of task in independent blocks
 Loose coupling between components
 Heavy use of dependency injection
Browser
 MVC as an example
 Model: Exchange and storage of data
 View: Representaton of data
Controller View
 Controller: Application Logic
Utility
Model
 Decoupling of unit tests
ORM/DBAL

12. Inversion Of Control
 Removal of static assignments
 Framework only works with abstraction of components
 Object graph is instantiated dynamically
 Separation of execution and implementation

13. Unit Testing in PHP
 phpunit: Status quo for testing in PHP
 Created by Sebastian Bergmann
 Originated as port of Junit
 Supports various features / extensions
 Framework for embedding tests in application
 Execution as test suite for an project
 Mocking of injected objects
 Code & coverage analysis
 Various functions for test assertions

14. Test Components in Symfony
 Unit Tests
 Enforce usage of dependency injection
 Testing of DBAL, model and relations
 Testing of components, utility classes
 Mocking of dependencies
 Functional Tests
 Testing page reachability
 Testing of page content and links
 Easy utilization for smoke tests
http://symfony.com/doc/current/book/testing.html

15. Behaviour Driven Development
 Enhancement to Test-Driven Development
 Introduced by Dan North in 2006
 Tests act as functional specification
 Missing link between developer and stakeholder
 Justify functional requirements at beginning
 Software developed against functional specification
 Specified in a formal language (no experts needed)
 Clear focus on functionality

16. BDD Test Specification
Scenario: Put item in shopping cart
Given the case, the customer wants to buy a movie
And his shopping cart is empty
And there are 2 movies in stock
When he puts the item in the shopping cart
Then the item should show up in the shopping cart
And the shopping cart counter should show 1
And 1 movie should be in stock

17. BDD Testing Bundles
Behat
Bundle
Integration of Behat into Symfony
Mink
Bundle Integration of Mink into Symfony
Behat Test Engine for executing Gherking test case
Mink Encapsulation of different browser drivers
Gherkin Formal language to describe test cases

18. Other Testing Bundles
 DoctrineFixturesBundle
 Preparation of test data sets
 LiipFunctionalTestBundle
 Simplifies preparation and execution
 Utilizes DoctrineFixturesBundle
 PSSMockeryBundle (Symfony2MockerExtension)
 Mocking of services in DIC
 Demarcation of tests

19. Continuous Integration
 Continuous process to apply quality control
 Various CI Systems available
 Bamboo, Jenkins, CruiseControl
 Successfull development process for CI
 Direct feedback -> Short execution times
 Frequent checkins
 Commits to trunk
 Automated test chain
 Automated deploy -> Continuous delivery

20. Continuous Integration
Automated Build
 Smoke Tests
 Unit Tests
Periodical Build
 Syntax Tests
 Smoke Tests  Coding Standards
 Unit Tests  Copy/Paste Detection
 Syntax Tests  Documentation
 Coding Standards
 Copy/Paste Detection
 Documentation
+ Acceptance Tests
+ Other intensive tests

21. Favoured Test Suite
 Test-Driven Development
 Testing influences whole development process
 Loose coupling of components
 Test chain according to granularities
 Smoke Tests: Routes, Firewalls (Reachability)
 Unit Tests: Modular components, Utility classes
 DBAL Tests: Entity, Relations and Repository
 BDD Tests: User Interface (Usability)
 Continuous Integration System
 Triggers test chain on each commit
 Verifies state before final deploy

22. Lessons learned
 Commitment to TDD needed
 Testing influences software design
 Testing takes its time
 Quality can hardly be achieved later on
 Full test coverage almost unachievable
 Regression tests need automated test suite
 Testing only way to ensure software quality

23. Questions
Questions regarding the practical
usage probably covered in part 2