We are eCommerce development experts who love Open Source and knowledge sharing.
Fernando Arconada interviewed Paweł Jędrzejewski, our Co-Founder, about testing and BDD in the world of Symfony & Sylius. He is writing a book for everyone interested in the subject of testing Symfony2 applications: Testing para Aplicaciones Symfony2.
I am entrepreneur and software developer, living in Łódź, Poland, with my wonderful fiancee. I created the Sylius project and started Lakion with my friend Michał. Our company is providing full-range of commercial services around Sylius, PHP and e-commerce.
I have started using PHP at the age of 14 and went through all the phases, from structural coding, through pseudo-OOP to what I am doing now. We all know that you can write really poor code with PHP, but that is true for any programming language. The notion of PHP being so bad comes from its popularity. It is by far the most used web language and there are many young and inexperienced developers working with it.
To write any bigger piece of Java code, you need to have a solid understanding of Object-Oriented-Programming and at least few Design Patterns. PHP makes it easy to start for anyone and that is the reason we often see low quality code in PHP world. That being said, things are getting better and better.
I am really excited about the revolution that is happening in our community. It is great that we are putting more attention to the development methodologies, testing in general and learning from other, more enterprise languages, which are much more mature in terms of OOP.
Older projects are still struggling with a lot of legacy code, but I am very happy to see applications like Drupal or eZ Publish moving to newer architecture with Symfony and moving away from the "old-way" of doing PHP. Regarding new platforms, like Sylius, Akeneo, OroCRM - Future of PHP looks bright and this does not only apply to big pieces of code, I see a great culture of testing arasing among maintainers of the smaller libraries.
Sylius is a fully open-source (MIT License) e-commerce platform for PHP and aims to be the ultimate solution for developers working on online-selling platforms.
It is both. Because of the architecture, it can be used as a framework. Our goal is to make the foundation even better and finish the full e-commerce platform. It is built from fully decoupled components and bundles. Finally, it is full-stack Symfony application and should be familiar for any developer working on Symfony.
I am the Lead Developer working with an amazing Core Team, which consists of seven people spread all across the globe, from San Diego to Singapore. We also have a growing number of contributors, about 150 people have submitted patches and nearly 190 works on the translations. We also have a lot of good souls submitting bug reports, providing us with feedback and promoting the project in their communities.
My first contact with testing was obviously using PHPUnit. It is a great tool and I have been using it a lot, but at some point I hit the wall. I wanted to change my whole workflow and needed a tool that will support this change. I was fortunate enough to meet people like Konstantin Kudryashov, who inspired me to dive into BDD and become passionate about quality. I did and can't go back.
In my work I always use Behat and PHPSpec for pretty much everything and with great results so far. It all starts by writing the feature descriptions using Gherkin, seeing the red color and then writing specifications for the code behind that particular feature. As soon as we see green color, we can refactor the code to be more elegant and continue! Few times I found myself implementing a whole functionality without opening the real browser.
No, the first bits of Sylius code were written back in 2011 and it was just a small set of simple Symfony bundles. At some point, I have created a "sandbox" application, which served as an example of integrating e-commerce components in a single application. At the time, we had just few unit tests and that's it. When I decided to abandon the sandbox and started working on the full e-commerce platform on top of Symfony, I wanted to do it right with both SpecBDD and StoryBDD. Since then, Sylius changed a lot, most of the code you see has been developed through TDD.
To run the phpspec example you just need to clone the project, install vendors through Composer and run a simple command:
$ bin/phpspec run -fpretty
This should give you a nice output of all specifications, which can also serve as a documentation of classes behavior.
With Behat scenarios, it requires setting up the test database, but then you can simply run:
$ bin/behat --suite=account
Our Contributing Guide has a dedicated part about BDD and a lot of people actually contribute using the proper methodology. Of course, sometimes people just write the code, but then we help them make the patch merge-ready by quite intensive code review and discussion. We use Gherkin scenarios as a way to communicate and explain the requirements for new features or even reproduce bugs.
When you use phpspec and BDD, you think in code and design your classes prior to writing it. People who use PHPUnit often name the tests after the class method it is supposed to test. With our approach, you describe the behavior of the whole class and code coverage does not make much sense. If you really do BDD, everything is "covered". I think Marcello Duarte explains it best in his answer to the StackOverflow question about coverage reports in phpspec.
In my case it were the people who inspired me to introduce a strong focus on testing and emergent design in my workflow. I think it is not a transformation that happens overnight, it is your evolution as a professional developer. I can recommend watching few inspiring presentations:
These are the tools that support a workflow, which in my opinion works best for me - BDD. They may seem a bit complex for someone new to testing and BDD, but they are staying out of the way most of the time, while you can focus on the code design and business requirements.
You will fell in love with phpspec, when you realize that it helps you to design better code and that testing is just a side effect. My favorite feature is thath phpspec is using frustration to drive you towards a better approach. It simply does not allow you to do certain things or make the hard to acomplish to show you that what you are trying to implement is not the best design. Mocking with Prophecy is great and simple as well. I can hardly think of any downsides, really.
Writing Behat scenarios is a great improvement to the communication among all the stakeholders and this works for open source as well. StoryBDD in general allows you get everyone on the same page about the business requirements. Only fool will think that writing code is the hardest part of our work. It is about understanding and focusing on the features which deliver the most value for our client. From a technical point of view, Behat as a tool is really nice to work with.
If you have a lot of scenarios and complex steps, the performance can be a problem, but this applies only to very big feature suites. With Behat V3 there is a really significant improvement and when pararell execution lands in stable version problem should be pretty much solved.
PHPUnit is a great tool and we should all be thankful for pretty much pioneering testing culture in the world of PHP. I enjoyed using it, but needed a different tools, which would help me transform my workflow into proper Test-Driven-Development approach.
I have never used Codeception and do not really know much about its internals. I recall it is using a bit strange syntax for writing tests, mixing Gherkin-like language, but in code snippets, which in my opinion kills the whole purpose of using a business-readable language.
I think the discussion around this question has been great and hopefully it helped some people to structure their own opinions about testing. Obviously my answer is no, because I am using TDD with great results and I see a lot of people around me benefiting from this methodology as well.
However, I do think that you miss the whole point of TDD if you have more lines of tests and you write tests just for the sake of having 100% coverage. To me BDD is a way to design my classes, by thinking in code and writing the code that matters for people who will use it. I think it keeps your focus in the right area.