Symphony.

I started going way off topic in another thread, so I thought I might give this idea a proper thread.

Behaviour Driven Development

Behat was inspired by Ruby's Cucumber project and especially its syntax part (Gherkin). It tries to be like Cucumber with input (Feature files) and output (console formatters), but in core, it has been built from the ground on the Symfony2 Components.

So, integrating Behat with Symphony development could be our chance to combine Symphony 2 with Symfony2 :D

Hah, at least something useful came from that other thread! :) It would just be a matter of implementing the generic step definitions using the Symphony class. Obviously it's not that easy, and I haven't looked at the core in a while, it's just figuring out which functions to use for the dealing with the database, creating sections, dealing with data sources, etc, etc. At least it's feasible!

I'm going to need one of you guys to explain to me exactly how this could be used. I've read over it, but it's been a long day and my brain's not entirely with me at the moment :P

I could use an example as well.

This is coming from someone who has had little experience working with rails and cucumber, but when I find myself working with our Ruby on Rails dev team on an application, the process goes like this:

• meet with the client to understand the goals of the application
• continue meeting with the client on a regular basis to understand each feature of the app
• write feature files to detail the behaviour of the user when using the application
• develop each feature of the application according to the requirements specified by the feature files
• test the application against the feature files
• submit each feature to the client for review
• requested changes are reflected in the feature files
• modify features of the application and test against feature files
• continue to build each feature ensuring that tests run cleanly before committing
• fix bugs that arise when feature changes cause tests to fail
• continue building iteratively to build sets of features until the requirements of the application are met

So the idea is to build the application that the client has requested according to very specific requirements that can be scoped, developed and tested. As the application grows in complexity, the feature files grow and form the basis for the test suite.

The process ensures that the application remains bug free as features are added, changed or removed. And the client is fully immersed in the process of developing the application, providing user experience testing against every requested feature.

A common understanding is that an application is never finished. Work continues iteratively as development sprints to build specific feature sets as part of an ongoing release cycle.

Hopefully I've described this correctly.

The same colleague who pointed me toward Behat also pointed me toward this resource for developing projects with Git:

• A successful Git branching model

@bauhouse

This Git branching model is Gold! Thanks for sharing it.

I'm more of an HTML monkey than a developer, but this all sounds very good. :)

Thanks for the Git branching model, too, which is very interesting. I'm getting more and more into version control. Number of merges made so far: 1. (In Mercurial. Also using Git.)

@bauhouse

That's the general idea, though our process can slightly differ depending on who is contracting the work.

It's called Behaviour Driven Development because the behaviour/functionality literally drives the construction of the code. You describe what you want in a very high level and logical way, which most lay-people can understand, and from these features (as they're called), you fill in the code as necessary. It works amazingly well for coming up with code that is nearly 100% correct. Unless of course, you forget to test for something, but in practice it works great.

When you run the feature files, a test database is created and populated (with whatever you want) and the feature files are run/tested against that test database. The difficulty of implementing Cucumber and Symphony together is that Symphony would have to recreate the sections/tables in that database each time the features are run, which from a performance perspective is fine; however, actually creating some generic wrapper functions to achieve this would require a deeper level of how sections/data-sources/pages are created with the Symphony class. Which, I haven't looked at for a while!

So let's say we're creating a contact form and we want to validate their email address. We have to create a Section in Symphony to hold the data, create an event to collect the data from the form and a page to display the form.

We would have to create some generic step definitions, or methods for doing this repeated work. From the command line Symphony would have to be able to do this, which I can't remember how to do offhand, $Frontend->SectionManager->create()? would be the basic idea.

Something as simple as this you probably wouldn't want to test because you trust Symphony's validations, but when you start dealing with more complex data, such as dealing with monetary transactions, it becomes more necessary.