 A couple of years ago, I started this new crazy endeavor. I started developing a new tool for PHP, which you nowadays know as Behat. I started to create it from the wrong perspective or started to think about the tool. I actually looked at the Cucumber project back in Ruby, and I thought, oh, God, that's an amazing way to do functional testing. And I kind of started to write the tool with this mindset, like this is an awesome functional tester. And then over years of developing Behat, I started to learn things which weren't actually related to testing. I started to learn the underlying principles behind BDD and Behat. I started to learn that there are more important things, far more important things than testing or even tools. So now I'm in kind of this weird state, and we have this running joke in our company where I spent four years building a tool, and now I'm spending time going around the world and teaching people that they shouldn't use it. Obviously, that's just half true. Otherwise, I wouldn't talk about Behat during this presentation. But I think that's enough for introduction. Who's me? I am BDD evangelist. I'm BDD practice manager at the company called Envika. You probably know me more as a creator of multiple testing or BDD frameworks in PHP, such as Behat, Ming, PHP spec, to Prophecy. I also contributed to different open source projects throughout my lifetime as a developer, to Symphony 2, Composer. And yes, that's totally a picture of me starting Behat four years ago. So what's this talk is about? I want to drive you through my understanding at this moment in time of what BDD is and how it is beneficial to use it. Of course, with Behat, but I will try to explain to you the underlying principles behind BDD, why it is important for you to understand them, why it is important for you to use them, and how they can make your life different as a software engineer or company owner or maybe a tester. So we'll start from talking about what is Behat during development, where it came from, what does it mean, why people created it. Then we'll talk about why would you use Behat during development for anything. Why is it beneficial to think about Behat during development, why is it important to shift your development or delivery process in the company to do BDD. Of course, then we'll talk about how to do BDD in the company, and only afterwards we will talk about how to bring automation into this process. And yes, I'm aware that it's Behat during development, we'll start talking about Behat in the second part of the talk, but it is important to go through phases one, two, three in order to understand where I'm coming from. And at the end, we'll close up talking about one of the most important concepts behind BDD that people kind of lose a lot, ubiquitous language. So let me start from talking about what is BDD. So back in 2009, then North, that's the guy who coined the term behavior-driven development, came up with this long description of what BDD is, and people just use it as a joke nowadays because it's so long and convoluted, but I think it fairly clearly describes what BDD is. So let me introduce it to you. And then North's mind, BDD is a second-generation, outside-in, pool-based, multiple-stakeholder, multiple-scale, high-automation agile methodology. Now, this sounds like a very overly cryptic sentence, even if it's a sentence. But at the same time, I think it clearly describes what BDD is and what BDD does because it does so many things on so many different levels. What I will try to do now, I will try to introduce you, BDD, from the perspective of every single line in the slide. So let's start somewhere around 1970. So probably everyone is aware with this diagram. So this is waterfall. People know that waterfall was a predominant way to deliver software before agile. What people don't know is that there was a way to deliver software before waterfall, and this way to deliver software was used all over the world, like in companies like IBM and companies like Apple at the beginning. So the way you were developing software before waterfall is you give a task or you have an idea as a software engineer. You go for two weeks developing software, and two weeks you come up with something working like Veeam or Bush. Obviously it did work for a small, exciting task, like creating a new text editor or creating a Bush. But it didn't work that well for the big project that started emerging around 1960, 1970. So Royce came up with this understanding that we need to have new approach to software development. We can't just rush into development and hope that things will go well in a year, because they wouldn't. So his approach was we need to plan things ahead. We can't just start working. We need to estimate, we need to plan, we need to capture all the requirements we want to develop when we want to do analysis. So the way it worked in Royce's head is we didn't have any planning, so we need to introduce at least some sort of planning at the beginning. The thing that people miss a lot is that Royce and his original paper said that waterfall or this approach might not work for big projects. It was designed to be used for mid-level projects, for projects that are bigger than Bush, but shorter than one-year project. People started to use waterfall and big projects anyway. And what they discovered is they have these prolonged phases. They have requirements phases that sometimes take nine months to capture all the requirements about the project. Then as soon as those guys capture requirements, they pass it toss it around the fence to business analysis. And those guys capture all the requirements, rehash them, find the things that, in their opinion, is the most important one, and then they pass it to design guys. And this is why it's called waterfall, because it goes in one direction. The problem with waterfall and long projects is the cost of feedback delay. That's why waterfall is considered a bad practice, not because it's like it's a stupid idea, it's a good idea for specific type of projects. But for long projects, it creates really long feedback delay. What is a feedback delay? Well, if you have requirements that you capture for a prolonged period of nine months, and then you do analysis, and then you go into software design or software architecture finally, the chances are somebody on the requirements phase in those nine months did some mistake that critically damaged architecture, so you can't proceed with designing software. But the problem is you already spent one year going into the phase of planning the project, and now you need to return back and redo half of it because of this critical mistake. So you kind of wasted half of year, and this half of year is a feedback delay. So this problem was acknowledged by multiple people in the community, in the software community. And some of them very smart ones came up with this idea where what if we do all those things, but we do them not for the entire system, but for one particular module, and we time box it for one, two weeks, maximum months. And this is how agile was born. So the whole point of agile is take this entire pipeline, wrap it up and say, we will do it, but we will involve every single person at every single stage of this process, and we'll also do it in the periods now longer than two weeks, or one month, right? So you kind of do the same process, but you do it so quickly and so efficiently that the worst case scenario is you wasted one week or two weeks of development, not half of year. So that was a huge breakthrough for big project management, or big projects management. But then some people started to evolve this approach and they introduced things like extreme programming. So the only way you can deliver with those small iterations is by making sure that you're not letting go of the quality, by making sure that you're actually delivering on the constant level of the quality. And that's why extreme programming has such a big emphasis on test-driven development. It's not because it's a fancy new methodology, it's because without tests, you cannot go with two-week iterations. You cannot constantly change a project without being completely sure that you're not breaking things. But then some people, like Dan North, he was a trainer in the ThoughtWorks back in 2003. He was teaching people to test-driven development and he struggled with people not being able to understand that the word test at the beginning doesn't actually refer to test. It actually refers to design or example behavior. So Dan North started to question the way we named things in the practices and he especially started to question, do we write tests in TDD? And the truth is, even Kent Beck, who introduced TDD in the first place, didn't treat tests as tests. What he actually treated is those were examples. So it's less of a test of an existing feature, it's more of an example of how this feature will work when it is working. And the thing that Dan North did, he just changed the way we named things so people can be introduced into TDD much easily. That's the whole thing with BDD, right? BDD is just a test-driven development where instead of saying tests all over the place, you're saying behavior and examples. So instead of writing tests, you're writing examples of how things will work, then you implement those examples and then you do design instead of refactoring, right? Makes much more sense. So you're kind of operating or designing a system based on examples of how the system will behave when it's done. And then showed this to a couple of colleagues at ThoughtWorks. One of them was Chris Mads. And Chris Mads looked at this and said, yeah, that's interesting, but you know what, that's kind of exactly the same thing that we're doing with our clients when we're doing business analysis. Chris Mads was a business analyst in ThoughtWorks. And what they did is they discovered that the same practice of talking in form of examples before you write in objects or define communication between them, the same practice is applicable to conversation between you and the client. So instead of acceptance criteria or in addition to acceptance criteria, they started to use examples. And that's why BDD is a multiple stakeholder methodology because it focuses on different stakeholders of the different levels of the practice. So then they did another change, is when you have this conversation throughout the system focused around examples, you create an environment where developers ask questions before anyone, product owner or stakeholder, pushes those answers to them. So you create the system where, instead of just saying to the developer, you need to develop, developers start asking, like, what's the next thing I want to develop? So this changes this agile methodology to the pool-based system, right? So developers ask product owner, what is an example for this user story to be implemented or what's the next story for me to implement? I'm kind of free. And if you look at those, at this diagram, there is two distinct layers in it. There is outside layer, which is purely talking with the business and talking about the business, and there is an inside layer, which is talking about the objects or implementation of the system. That's why BDD is outside-in methodology. Also, if you look at those layers, the outside layer is obviously a system layer, right? It's like how your entire system behaves as a wall, and internal thing is units layer. That's why BDD is multiple-scale. That's why in BDD, you usually use both unit tests and acceptance tests together. You're not choosing one over another. And then, obviously, in the last thing, BDD is high-automation methodology. There are tools for different layers of your BDD stack of how you develop things. So obviously, on the client-facing side, Behat is the known tool in the PHP community. On the object-facing side, PHP spec is the most prominent and known tool for defining how objects behave. So this is a prolonged definition of what BDD is. But if you'd like to put it in the very, very simple and distinct definition, at least, did it better than anyone, BDD is when you use examples in conversations to illustrate behavior. That's BDD. That's all there is. So as soon as you have conversation about the objects in the system or about the behavior of the system with the clients or with stakeholders in form of examples, in order to illustrate behavior, you're doing BDD. That's all there is to it. So why BDD then? Why using all this craziness is important and how can it help you? Well, there is a second part of this definition, crazy definition by Dan Lord, which is BDD describes a cycle of interactions with well-defined outputs resulting in the delivery of working tested software that matters. So what does it mean, delivering software that matters? So if you look at the way we deliver software nowadays, predominantly, we do this thing, a gel. And the reason why we do this thing is because we understand that even though we plan to deliver those six features ahead of the time, we know that things will change somewhere around feature number three or somewhere around feature number four. We can't predict those changes, but we know they will happen. So the second thing in this project, in any project, is a change. So we want to be able to, as soon as we face this discovery, to change direction of the project. Instead of those last three features, do some other three features. Spend the time of the project and budget of the project doing the things that are most relevant at this point in time. And then after doing another feature, you can again change the direction of the project, go into a completely different thing. And it's like this for months, and then you might end up with something like Google Buzz, and then you close it because nobody uses it. Right? And it's like you kind of, you adopted to the market, you adopted to technologies, right? You did a gel. Why didn't it work? Well, the truth is, if you look at the researches around the world about how we deliver software and how people use the software, it says a really scary notion of how people use it. So, Standard Group states, but based on their research, 45% of features we deliver on all the projects are never used by anyone. Almost half of the features you deliver on your projects are never used by anyone. But wait, it gets even better. Only 90% of the features are rarely used. Not only. 90% of the features rarely used. 16% of the features used sometimes. 13% of the features used often. And only 7%. 7% of the features are used always. Right? Out of your 300 user stories backlog of requirements, things that are required only 7% will be actually always used by your users. So, the industry level notion is we deliver waste in form of hundreds of features a year. Right? And, as a matter of fact, we started to think about it in my company, a year and a half ago, and we started to look at things that client care most about. And what we discovered is, which is highly controversial, but that's what we discovered, your client does not care about your scope. Right? He doesn't care. He doesn't care how many features you deliver. He doesn't care which features you deliver. It gets even better. Your client does not care about his budget. We just discovered, like, I know what you might think, he's talking about removing from stage, but wait for it. I think your client cares only about one thing, and it's his business. The only reason why he does this project why he came to you is because he wants to improve something in his business. And the only reason why your client worries not cares about his budget and your scope, it is because you don't care about his business. Right? Your client comes to you and says, I have this budget. What can you do with it? It's kind of saying, I have no idea if you will help me with my business, but try at least something. Here's your limit. Right? And that's the same thing with the scope. It's just like, I have this amount of money. I have no idea if you will help me with my actual thing that I worry about with my business, but at least I want you to help me with my budget features. Maybe some of them will help me. And the solution is very, very simple. Start talking with the business. Right? Start asking them, what are they doing? What do they want to achieve with this application, with this website, with this Drupal website? Why do they want it? Is it because they want to increase their marketing revenues or decrease marketing revenues? Is it because they want to increase overall revenues as a company? Start asking business questions. Start caring about what they're trying to achieve with this website. And use business examples in order to do that. Right? Ask them, can you give me an example of how people will use it, and can you give me an example of how it will improve your business? Overall, try to think less about delivery features and try to think more about delivery features. And that's in essence what BDD helps you to do. It helps you to ask proper questions and to get proper answers before you make mistakes, before you deliver those 93% of features that rarely will be used. So how to do BDD? How to apply it in your company? The first thing I want you to understand about BDD is it is a general methodology. So everything that a general manifesto states, like individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan, those all are applicable to BDD, and you should follow them if you want to be efficient with BDD. So for example, individuals and interactions over processes and tools have a conversation. Right? Do not start or any other BDD tool. Start from having conversation. It is much more important than using the tool. Working software over comprehensive documentation, you probably heard multiple times that using tools like Behats allows you to create comprehensive documentation for the project and maintain it. Well, know what? Working software is much more important than comprehensive documentation. If using tools, BDD tools or BDD methodology doesn't help you to write software easier than you're doing something wrong or maybe BDD doesn't work for you. The whole point of BDD is to make it easy to write software, not harder. Customer collaboration over contract negotiation. A scenario or example that you're talking with a client is not a promise. It could change. Not only it could change, you should be able to adapt to this change. So, in a couple of sentences, having a conversation is much, much, much more important than capturing this conversation. And capturing this conversation is much, much, much more important than automating the conversation afterwards. So the simplest way to start with BDD is start from the conversation. Start having a chat with your client, right? Start talking with him. Start asking questions. So, for example, when he comes up to you and says, when browsing an article, users should be able to see related articles. Start asking him why would anyone want this feature? Who will benefit from this feature when it's done? What does he need in order to get this benefit? For example, in order to have that cool feature everyone else has, right? Related articles. So that's the wrong answer, right? It's like you're just ripping off your competitors, including the features that nobody else uses. In most cases, you will rip off features that nobody else uses. The actual answer is in order to read more interesting articles as a user. Well, user is the most generic way to define people that use your software. User is like, is anyone and no one at the same time? In this particular case, when you're reading your articles, it is definitely a reader, not a user. And the feature that you're trying to deliver is related articles to the one you're reading. So in order to read more interesting articles, as a reader, I need to see related articles to the one I'm reading. Clear benefit, clear beneficiary, really clear why this feature should be in the project. And when you have more than one in the list, you can decide by which feature delivers what value at which stage. And you can show it to your stakeholder and ask him to prioritize. Give this list to stakeholder and ask him what is the most important bit to be implemented at this stage of the project. And he will be happy to put members next to them. He will say, in order to read more interesting articles, that's kind of the benefits I'm aiming for. That's a high priority. Work on this one. And then you have your feature, right? You want to work on it. But this thing is just a narrative. This is just a user story in the classical Agile terms. What it misses is, it misses this classical promise of Scrum or Agile having a conversation. You have your user story, you didn't have a conversation about how this story should be delivered, how this feature should be delivered. So this is where BDD comes in and it says, not only you need to have conversation, you need to have this conversation in a very specific format, which is examples. So you start asking questions like, okay, seen related articles to the one you're reading, can you give me an example? What is the simplest possible example of this feature working? Okay, well, the simplest possible example of this feature working is seen on article with the same word in the title. So if we have two articles and you probably see it, okay, can you give me exact example with exact article how it will work? And this is where you go even deeper. So the format that people use most, it's not the only one, but people use most with BDD. It's given one then. So given a context, when a sum event occurs, then the outcome should happen. Then some expectation. So in our case, there is an awesome article and there is DrupalCon schedule article. Both of them contain DrupalCon, right? When I read the DrupalCon is awesome article, then the DrupalCon schedule should be in the list of related articles. Right? That's it. Very simple example of behavior you're expecting. Then you start asking more question. Can you provide me different example where it works differently? Maybe not titles. Oh, yeah, right. We have tags. So we can see an article with the same tag in the list of related articles. And you can go on and create another story. Given there is a DrupalCon is awesome article target impressions and there is a Drupal8 is great article target impressions, when I read the DrupalCon is awesome article, then the Drupal8 is great should be in the list of related articles. And then you can start asking questions in which context this wouldn't be true. And you can come up with examples like not seeing an article with the same word in the title if it is ignored keyword. So you can have some commonly used words that you don't want to consider to be considered as related keywords. Okay? So this is your user story and this is your examples of behavior of how people will use it. You print it. You give it to developer. Developer puts it on his table, follows it line by line, implements it, you're done. You're done BDD. Right? Notice no automation. It's absolutely fine and possible to do BDD without using BeHat or using Cucumber. You can do it because the essence of BDD is talking in form of examples. Conversation is more important than tools. So some tips and tricks. There is a set of key questions you should ask your stakeholder or product owner when you're having this example of conversation. The most simple one in the basic one, can you give me an example? We should not allow payments over 10 pounds. Can you give me an example of this? What do you mean? Can you give me an example of somebody paying more? What happens in this case? Is there a context in which this example wouldn't be true? Is that the only outcome or is there other outcomes? Does the user have full control over this feature? Or maybe somebody else can have a control of it? So that's BDD in a nutshell. But you know this talk is called behavior-driven development with BeHat. So automation should kick in and subface. So even though I said you can do BDD without automation, automation adds a lot of value on top of it. But only if you have this conversation in the first place. So if you look at this feature, it is very, very structural. And it's like every single feature has this same format in which it is written, just because you want to bring structure in your examples. But we know as a software engineer that everything that has structure can be parsed. And that's what BeHat does. It just parses the features that you created together with your stakeholders, with your product owners. And what BeHat does, it asserts your application against your features. Right? It takes your features which are examples of application working. It takes your application, actual application, and checks if they match. That's all there is. On the very basic level, BeHat is a very basic tool that does one thing but does it well. So instead of just printing this feature that you had and giving it to developer, you just copy-paste it through your chat messaging system to developer. He takes it, dumps it into .feature for text file inside the project, puts it into the features folder. It's just .txt file. Installs BeHat via Composer or by downloaded BeHat file. And then runs BeHat-init. So BeHat-init creates test suite. Actually, it creates just this one class for you. It's just a simple PHP class that implements one empty interface. That's all there is to it. The reason why this class is there is because you kind of need to explain to BeHat what does it mean this feature working in your application. You need to explain to BeHat how he should test every single step you wrote in your scenarios in your examples. How should it test it against your application or in your application? BeHat is a mapping mechanism between your application and your features. So next time you run BeHat, it actually tells you, hey, I have no idea how to test those things. I actually can't find the matchers or roads for those steps. But don't worry, here are a couple of step definitions. BeHat generates methods or those routes for you automatically, together with a matching pattern. All you need to do is just copy it from the terminal and pass it in your feature context file. Or you can just run BeHat with dash, dash, append, dash snippets. It just takes them and copies and passes them into the feature context class for you, so you have them there without even copy pasting. Then you run BeHat again and you have this thing. So this is where your feedback loop starts. You run your feature, you have two scenarios, one is to have a lot of steps. BeHat found step definitions for them, but you have pending definitions. Ending definition means BeHat still doesn't know what to do, but it kind of knows that you started to define to tell him what to do. And this is where Outside In process kicks in. You're kind of here. So you go to your contacts, you start from one step that is different color than green, the first one. And then you have a new code that you can use to create a arg article. Your name arguments to name article. And now BeHat will not only pass the step definition from your context, it will pass whatever there is in placeholder name as the name argument to your method. And then you can write code like this. So you create a new node internally because you're working with Drupal, and you push a node into the database. So this git driver is a method call from BeHat extension, which I know Jonathan is in the middle of updating to BeHat 3. But that's essentially what you should be able to do with it when it works. And it already does work with BeHat 2.6.2.5. So what you do here, you create a node, you push a node into Drupal, and you give the return node object into this node variable. You run BeHat again, first two steps pass. Because they're exactly the same step or exactly the same thing in BeHat's mind, the only difference is you pass different arguments there. So you created two nodes now. You kind of changed the color. You got from red to green. But now you have another step failing. So again, in the red state, you go into your context class and you add another step definition. And in this case, we're using Mink to go through the web interface and actually get this particular node page. Right? We run BeHat again, and another step passes, right? We're getting to this node page because Drupal successfully created it. Again, the green state. Again, the next one is yellow. So we go into the context class and we get a new version. Then the title should be in the list of related articles. So what we do here is we assert that specific element on the page with CSS.related class has this text inside, this title thing inside it. You run BeHat again, and this is your first real failure, right? TextDrupalCon schedule is not found in the element related. So you don't related element on the page yet. This is where you go and actually start adding it into your web page. This is where you have this red state. How do you add it? Well, you start from pushing exception or failure down the road, right? You're saying, OK, it's really, really hard to solve exception on this layer. So I will push it down the road to the specification or unit test layer, or maybe just template or configuration layer. And you start fixing small issues along the road there by making things green. And hopefully, at some point, every single change, everything single red, green, flickering in the lower layer will make your outside layer green. And that's the point where your scenario, your first scenario becomes green and you're done with part of functionality. So that's BDD in a nutshell. That's how B-hat works, right? There is nothing else to it. Have a conversation, write this conversation down, pass it to the tool, and just use it as a developer to test-driven develop your application. Except instead of using tests, you're using examples of how your application should behave. This is the last bit of this presentation. There is this thing called ubiquitous language, which is second core concept to BDD alongside examples. So if you need to understand two things about BDD, it's that you have conversations in form of examples about the behavior, and you have those examples in language that is ubiquitous to your domain. Every single company, every single business, has its own language that you want to reuse when you're talking about features. So how does it look like? Well, it surely doesn't look like this, right? So this is an example of bad feature and bad by multiple reasons. One of them is that you hook yourself to the user interface. Those things. I visit the node 15 page. Then the element with this class should be on the page. What you're essentially doing here is you're locking yourself to UI. And locking yourself to user interface or any other layer of infrastructure is a very bad idea. There is a multiple reasons why this is a bad idea. First of all is infrastructure tests or UI tests are inherently slow. They will always be slow. You can try to optimize them and automate them by introducing parallelization or multiple servers running your tests in parallel. Overall, it still will be slow, right? And you will kind of fight with this forever. The right way to solve this problem is take your behavior specification and consider different ways how you can automate it, how you can test this feature, right? What should you write in the context class in order to make it pass? So in this case, you can't do anything because it kind of talks about user interface. You're forced to go through the user interface. But if you imagine the world where you're not going through the user interface, you're just talking about abstract things like articles and reading articles, you can actually touch Drupal code directly. You can send call functions, call classes directly, which will be 10 times faster than going through UI. Now, I'm not saying that you don't need to have UI features in the project. I'm just saying you need to have much less than you probably will have by locking yourself to UI. So by not locking yourself to UI, you give yourself more opportunities today and in the future in order to push all the tests down the infrastructure. You're opening the door where if your test would become too slow, you can refactor 50% of the tests to be actual unit tests or integration tests inside your context, and they will run 10 times faster. So let's say we want to isolate ourselves from the UI. So you can come up with this thing. Given there is a node for 15, when I visit the node 15 page, then the node element should be on the page. Right? This doesn't block you to specific UI, except maybe the page word, but it still is a bad feature. And the reason why it is a bad feature is because it doesn't tell me anything about the business. Right? It doesn't tell me what is a node. It doesn't tell me what is the node element that I'm expecting at the end. It doesn't tell me what is the node page and what I'm doing when I'm going to the node page. Why I'm visiting this node page in the first place? It doesn't give me any hint other than I'm using Drupal. Right? And it doesn't help me to understand business. It actually obscures every notion of business from my feature. The right way to put it would be, given there is a DrupalCon as awesome article, when I read the DrupalCon as awesome article, then the DrupalCon schedule should be in the list of related articles. I missed one given there. So the reason why this feature is much better than the previous one is because it's full of information about the business. Like, how do you call things in your domain? How do you call things in your blogging platform? Well, we know that, for one, you call things articles. And we know, for one, that you, whenever you want to do something with articles, you can read them. And we know that there is a list of related articles. So what you can do with this information, you can take this information and push it back to the code level. You can use it in order to name your classes or methods if you're designing your system. All those questions that you have with object-oriented programming, like how to name this object, how to name the method of this object, where to put this function, they all go away here because you're essentially having this information and you're pushing it from your business domain, from the language of your business. So what I'm trying to say here is ubiquitous language is the thing. And ubiquitous language is not the language of your business. It is not the language of developers. It is a language that both business and developers create together in order to talk about the application. And the wonderful thing with this last feature also is as soon as you innate this culture of talking about the business and behaviors into developers, into testers, they will start having conversation about it in front of Product Owner. And Product Owner not only will be able to understand them, he will be able to correct them or he will be able to introduce better solutions. He will say, in the business actually, guys, this works this way. He can overhear discussion between two developers talking about some complex concept in the way they structure articles and they can say, so, like, we have an article and we put it into article archive. But then how do we know how do we get this article from the archive? And then if Product Owner overhears it, he can say, well, there is the whole mechanism in our business how we can get things out of archive. We have this thing solved on the business level. You just need to implement it in the code. And this is how you solve architectural or technical problems by having business conversations with the business. So a short recap. What did we hopefully learn today is we looked at what behavior-driven development actually means. We looked at why behavior-driven development is important for you as a company and why is it important for us to think about values that BDD exposes. We looked also about how to use BDD without involving any sort of tools, except examples. We then looked at how we can automate our examples using tools like we had. And how ubiquitous language can help us to make not only steps faster, but the conversations between us and the Product Owner much more efficient. So this all kind of sounds experimental and crazy. The truth is we are doing this for our clients. So I'm from the company called Invika, which is kind of a conglomerate or group of companies, including Sensual Labs and Session. So we do this for symphony projects, which is kind of symphony. It's the couple that's easy to test symphony. We do this for Magento projects, all right? Which is if you think it's hard to test things in Drupal, well, it's harder than Magento. And what we teach others how to do it, and what we discover is the more you talk with the business about the value, the more you talk with your clients about what they can get out of this project, how their business can transform, the less they want to talk about the budget or the scope. So we literally have this process at the company called Discoveries, where we go through two weeks of talking with the clients. And during those two weeks, we ask those questions. At the end of two weeks, clients, it doesn't matter how old-school client is, he stops caring about how much money he will lose with this project or how much features he will get at then, because he started caring at this moment that we can help him to earn money. So instead of worrying about how much he will waste or lose on this project, he suddenly thinks about how much he can earn. So that's it for me for today. Do you have any questions? Actually, I have two questions. I've seen lots of happypats here, but how would you recommend to deal with bad behaviors that happened after you developed the main features that maybe didn't catch? Can you give me an example? I don't know, a bug. A bug, like? I don't know, the infinite scroll broke. Right. So the first thing you want to do is you want to identify, is it a bug in the business behavior in something that is really important for the business, which could be infinite scrolling? Or is it a slight issue in the way you present information? So in any application, there is two layers. There is a business automation layer or core domain of your application, which actually does the job. And then there is a feedback layer, which is your UI thing. So the question you need to ask is just like, continue scrolling if it doesn't work. Does it damage the business? Yes. So you need to be sure, and as soon as you're sure about, does it actually impact the business, you could have this conversation where how do we make sure that we're preventing this from happening? Generally, the way you use examples and the way you have this conversation, you're not talking about defects or bugs in the UI or in the whole application. You're thinking about defects and bugs in the logic, and you're not talking about that, you're not talking about the core domain of the application. So for example, if your core functionality is showing top 10 articles and then when you scroll more, you can see more, like, 10 more, then that's the behavior you will cover. So that's how you will develop it. You can develop things in the different layers. So in your case, when you have rich front-end behavior, like infinite scrolling, you might have one feature and test it on two different sites. I might have one particular example or gerkin feature, this feature file, and use it on the front-end layer with, like, cucumber.js, for example, and test, like, infinite scrolling there, just purely in the browser as a unit test or integration test on JS side, and then I will have a separate one that tests, like, API on the back end, because that's probably how you will implement it, right? You will implement it through API. There's a feature that describes this behavior if this behavior is important for the business. And then I will try to find a way how to automate it in the way that it is efficient. And it's, like, going end-to-end. It's probably not as less efficient in this case. Kind of went all over the board. So I think the answer is, how do you discover those things? The rule of thumb that we use is, as soon as, like, nobody comes up with an edge case during the initial discussion, and you have three people in the room usually having this discussion, test their developer and client. So if no one of them came up with this edge case, probably it's not that important for the business in the first place. Maybe it is, so then you audit later on. But you don't add edge cases just because there are edge cases into your scenarios. You add things that are important for the business. So as a good example, like with scrolls, infinite scrolls is kind of hard, good example from the different perspective, you have form validation, right? So as a business, you care only about two binary states. People with correct data can fill in form and we record it. People with incorrect data cannot proceed further, and we're not recording them. That's all business cares. Everything else is just a feedback to the user to help him to fill the right data. So you will literally have two scenarios because that's the only thing that business cares. And then you will have separate, like separate small workflow where you will try to improve UI, either with JavaScript front-end validation or maybe back-end validation. But that's kind of a separate thing altogether. Did that answer it? Yeah. Second question is, with an already-existent project, how would you start integrating BeHat to kind of, you know, bring it in and maybe also covering the old features that weren't covered? So, again, you always start from conversation. Like, you find a way to have this conversation. So, and it depends how development happens. Like, if you implement new features on the project, you have this conversation about the new feature. You write it down, you automate it with BeHat. Right? There might be bugs in the existing system or some changes that you want to introduce. And, obviously, you didn't describe how they worked in the first place. So you need to backtrack a bit and talk with your stakeholder about, like, how this feature was intended to work in the first place. And you have the same conversations a lot. Can you give me an example how it should work? So you still can have those conversations on existing projects. As a matter of fact, we use it and it's like it has a lot of benefits. If you have a system which you have no idea how it works, that's a very efficient way to discover what it actually does and how it should work and fix a couple of bugs along the line. Thank you. Welcome. Anyone else? Okay. Thank you very much. If you're interested in us helping you in the form of training, coaching, or maybe sitting next to you on your project and start helping to bootstrap it with all those wonderful things I talked about. Also, we have had stickers. Find us on the stand number 309. Thank you.