Fullstack BDD wrap up
Yesterday weâve given our first talk with Marcello about fullstack BDD in PHP (yesterdayâs talk was about Symfony2 particularly) world. And i think it was great.
About the talk
Talk consisted of 2 parts - theorethical and practical. In the first part, the main goal was to show people importance of SpecBDD and itâs place in BDD stack as we already assumed lot of people know what Behat and StoryBDD is all about. Weâve put lot of passion and ideas on attendees in this part, but there was nothing in the first part of talk that we werenât doing on other conferences before. And there was always a missing part. On every conference i was talking about Behat, about itâs place in the development process and everybody tended to agree with me, though i still didnât seen wide understanding of fullstack BDD in PHP world. People still doesnât see BDD tools as logical parts of their development process. Everybody understands, that itâs awesome to use tools like Behat, but nobody actually knows how development process with them look like before weâre starting to teach them with Marcello closely. Thatâs where second part of the talk came from.
Key idea to understand in the second part of the talk is that our plan was not to show particular commands or actions your team needs to do, as itâs really impossible to show - things warry from project to project too much. Idea was to show that fullstack BDD is not only absolutely possible in Symfony2 applications, but looks like logical, missing link in any development process. In simple terms, idea was to burn fire in your hearts about the process itself. To show people goal and force them to seek knowledge.
But yeah, weâve showed alot in 20 minutes. It couldâve look confusing in some parts as it were live coding anyway. But we didnât wanted to show you something abstract or not real. We wanted to show you real life development process based on BDD. I donât know if you noticed or not, but we almost finished (only template was left) one scenario implementation during 20!!! minutes of life-coding with comments and Q/A session. 20 minutes to write part of application, scenario (functionally tested) and specification (class tested) for it. Weâve shown on real example, that âweâre not using TDD, as those tests take too much timeâ argument doesnât work anymore. At all!
Main goal of the talk could be described as âunrecoverably infectâ. Of course we couldâve just showed another set of beautiful âBDD in PHPâ slides for 1 hour as we did enormous amount of times before. But we wanted to do something really different this time around - whatâs the point of showing you results of interesting research, that you donât even know how to apply into real life. This time we wanted to show you the final result. How BDD looks in real life development. And to make you hunger about this stuff. If you are, hereâs the next logical step for you ;)
About the tools
Weâve also talked alot about tools and even presented new one during presentation. But there wasnât enough time to make really clear reasoning behind those things. So let me do it right now :)
The Good, the Bad, the xUnit
From some feedback i understood that weâve looked like biggest critics of the xUnit out there yesterday. Itâs far from being truth. As a matter of fact, i even said multiple times that âthereâs no problem in xUnitâ and âthereâs nothing wrong with tool itself - it does the job really wellâ. Idea we were pointing out is that xUnit was been created for some particular set of problems and it does the job really well solving them. Thing is, people just loosing track of what this particular set of tools were created for and start using it for wrong job. Have you ever tried to use hammer as your screwdriver of choice? And after that if iâm saying that âyou shouldnât use hammer for thatâ, does it mean that hammer is a bad tool? No. It was just created and optimized for different needs.
What is the problem xUnit tries to solve, you could ask me. Testing your code, i would say. Existing one! This idea sits deep deep inside any xUnit tool out there, they make it extremely easy to test/express your units in the assertions and testcases. Code coverage, mocks with fixed amount of calls - those all parts of the big picture, final goal any xUnit tool tries to achieve - be sure to notify you about breaking something. Thatâs the goal. Give you tools to create code breaking notifications system.
Ok, xUnit was created and extremely useful at testing code. Isnât it what we need in TDD or SpecBDD? No, itâs absolutely not. One toolset (xUnit) makes sure your code doesnât break and thatâs its main goal. Another toolset (TDD, SpecBDD) makes sure that youâre building correct and logical interaction system between objects in your system. One is aimed on testing something that is already exist and completely described (at least in the UML or on the paper), another one is aimed on describing something new. And in this lays the main difference between two. You donât see the difference now, just because most of the SpecBDD or TDD tools are trying to provide just a different syntax without going deeply into understanding their goal. It was even the case with PHPSpec1, which Marcello was developing for couple of years now. And thatâs something that we wanted to change completely with PHPSpec2. We want to make difference so obvious and clean, that you could easily see the goal of the tool even without using it (aka âfrom screenshotsâ).
The difference
What happens when youâre running xUnit testcase for non-existing class (and we agreed, that with TDD and SpecBDD weâre describing code before writing it)?
Mind if i tell you what just happened? Tool yells at you. It yells because something went completely wrong in its opinion. It did itâs job really well - it made your life extremely uncomfortable because youâve broke something. Problem is, in case of TDD, the fact that something doesnât exist or broken shouldnât be something extraordinary, it should be the way you develop applications. Instead of yelling at you, tool should talk with you and provide solutions. Because it knows, that youâre still in the process of finding best design, not testing something complete:
Is PHPUnit a worse tool in this particular case? Yes! Is PHPUnit a worse tool in any case? NO! Itâs just a hammer and you should stop using it as a screwdriver.
You see, goals are different. PHPSpec2 builds a shell-driven conversation with you, because it assumes youâre not done yet and you need a help:
xUnit yells at you, because it assumes youâve broke something working just freAKING NOW:
And here comes an interesting part. What happens when youâre using wrong tool for the job? Confusion! Youâve heard thousands of times that youâre not doing TDD because youâre lazy or because youâre not experienced enough. In our opinion, youâre not doing TDD (read SpecBDD), because youâre feeling incomfortable when someone yells at you every minute. Itâs like trying to do pomodoro with WWII air-strike alarm as a timer. Air-strike is extremely useful during war, but makes you extremely uncomfortable during your workday if using it as a timer.
Everything in PHPSpec2, including syntax and CLI interface works for its main goal - to help you describe your application logic. To help you understand how your objects interact with each other and what job they should do. Does it matter how many times your mock method will be called inside object? In some cases - yes, in most cases - no. Thatâs why PHPSpec2 will never ask you this question explicitly. Because you donât need to answer it during design phase in most cases.
Everything in xUnit, including syntax and tools around works for its main goal - to help you understand that your applicaion is not broken anywhere. Does it matter how many times your mock method will be called inside object? It doesnât harm at least, as you already know this number (code is written, right?) anyway. and if this number goes up/down, it could potentially lead to a bug, right? So thatâs why it forces you to answer this question every time. Because in this case, it could be important.
There is a huge difference, that most testing tools were hiding from you for years. Not anymore!
Wrap up of wrap up
During the talk weâve shown lot of concepts to you, but most important one was - fullstack BDD is not only possible, but extremely awesome in PHP if youâre using it with right tools. And if you were confused or missed something during the process, thatâs exact reason why this repo was created for. Follow commit messages and evangelize BDD on your working place. And see you on the next conference ;)