SF2 Demo is a BDD demo, not a UI demo

This is a more expensive demo that I wrote. The source is available as a compressed bundle. Further reading on Symfony will be published symfony2-overview.

Problem Desc

For this exercise you will be asked to build a data-driven web page with the latest stable version of Symfony2 framework.
Features you are going to build are described by user stories. Each user story contains the acceptance criteria. It also might include some technical requirements or constraints.

User stories converted to test conditions

  • generates valid HTML, with a list of articles (not a test condition)
  • REST-like URL space (the relative URLs listed in this text function)
  • I will make this support mobile, but not emphasis the front end that much
  • for /football
  • html passes tidy ~ will do this last
  • assert nothing in “preview”
  • assert empty data source has error message
  • assert malformed data source has error message
  • assert general information is first item
  • assert each item has a publish date
  • assert each date is as YYYY-MM-DD HH:MM
  • assert each item has a description
  • assert each item has a title
  • assert each title is a A to a valid URL
    • for /football/report
  • assert only contains items of report type


I poked around, and pulled up an XML library. I initially thought I should be able to use the SF2 XML library, the problem domain is the same as parsing the SF2 config files, which may be in XML. This is not encouraged, if its possible. I looked at sabre, which seems to wrap simple XML (part of the PHP language). This only applies to XML with namespaces, so I discarded the popular library.

I am currently using Halilim's XML iterator.
I have implemented one parser for the RSS feed. If one swapped the SkyRSSSsource class for another DataSource, it would allow the multiple sources as requested. It would be nice if the object building code in the controller could be moved into a factory, but no time here.
Currently the settings must pass from the URL, so the controller holds more code than is ideal.
The demo isn't complete, as I skipped any CSS or JS at all.


From that spec, I can accurately write a BDD.
The spec states less focus on front-end, so I am doing headless tests. This makes the tests more portable/ less brittle.
I am using Goutte, as this is no time cost to install.
I put the BDD tests inside /features.
Pls note, I couldn't get the Goutte implementation of selectors to work for the error reporting lookups.
The code does report those errors. If you read the Behat PHP file, you will see my attempts to get PHP to report what has been extracted, but Behat disables output.

As it is necessary to demonstrate error handling in the tests, I built fixtures for the necessary states. These are included in the source bundle (in Tests/Fixtures), and as follows. One may externally choose the file being processed, via an extra level of parameter in the HTTP request :

  • file 1 ~ valid file
  • file 2 ~ empty file
  • file 3 ~ corrupt XML ~ should not occur in real life
  • file 4 ~ preview items & data
  • file 5 ~ report items

Composer change list

These may already be present on your system; but are necessary.
The current stable edition of SF2 is 2.5

Requires list:

  • “behat/behat”: “2.*@stable”
  • “behat/mink”: “1.*@stable”
  • “behat/mink-extension”: "*",
  • “behat/mink-goutte-driver”: "*",
  • “behat/mink-selenium2-driver”: "*"
  • “behat/symfony2-extension” : "*"
  • “halilim/xml-iterator”: "*"

“config”: {
“bin-dir”: “bin/"

To operate (on your server).

  • Copy this code tree into your symfony src directory.
  • Add a reference to the routes.yml to your master routes.yml.
  • Rebuild your caches.
  • Access the URL.

What I would I ~ author ~ change ?

  • Add some CSS if you want good readability.
  • Add a better way to choose a data source.
  • Refactor the code that processes GET arguments into an XML objects into a factory.
  • The choice on what RSS feed to read.

Some similar articles in legacy