 Felly, we'll start by really quickly the stuff that you don't care about. I'm a senior software engineer at a company called Viva IT with the folks in Orange Hoodies at events if you ever see us. Come and say hello, we're quite friendly. Bronti on Twitter. I also organised php's Midlands in Leicester. Joined in. The slides are available on there as well if you do want to follow along as well as the codes, the code for the talk. And any feedback after the talk will be really helpful so thank you in advance. Ydych chi'n gweithio dechrau'n gweithio'n gweithio ar gyfer i gynon a'r dweud yn dwyllidd. Ric chi'n gweithio ar gweithio broker dechrau'n gweithio. Y dweud y gallent y gallai trafodaeth i fy ffordd, er oedd y cwrs ar gyfer o'r gweithio'n dechrau'n dweud o fyw o ddatganiaethau edgesig a dweud. Rhyfon chi'n i'n tyniad adull o'u amddangos, nad yw chi'n pob chi'r cymerau a nad yna'n gweithio'n cael ei gweithio'n gweithio. y dweud o'i gwneud yn dros y gallu o'r mawr. Bdd wedi bod yn fyw ddysgu'r dyfodol ymlaen gynnig, i'r ddeud yn ychydig i'w ddigon i'r ddweud i'r ddweud i gael y ddweud. Mae'r ddweud wedi rhoi'r ddweud yn fwyaf o'r dyfodol, yn y gallu ddweud i gael itrfyn. Yn ddwy'r ddweud i'r ddweud. A'u ddweud o'r ddweud o'r ddweudio, oeddwn i, wedi, ddweud i ddweud i'r ddweud i'r ddweudio. gw burden, diweddaraeth, yr hwnnw, gyda'r garrion i'r ddysguitysthaf yn fathion i mi wedi nodi yn bwysig. Fyddwn yn fathion i'r fathion i'r byd, nid gyda'r bwysig. Mae ydych chi ychydig yng Nghymru. Mae ddiwg am'r Llywodraeth Pffaith i'w reliable, niew rwyf i'r Llywodraeth Pffaith Ydwy, rwy'n gwybod i'n gweithio i'r Llywodraeth Pffaith yng Nghymru. Mae gofyn y odd oherwydd ei cofnod yma ei hwn yn deall gilydd y cydnod ar amser yn y cydnod. Roeddwn i'n gweld cydnod yn cael y cydnod, y dynod wedi rhoi ei fod yn y cydnod o'r ddaeth cyfnod. Roeddw'n meddwl yw cyflwynt ar gyfreion gyda'r cyfrifiadau. Mae'r cyfrifiadau'r cyrfrydd, ac mae'n meddwl y ffocws ar y cyfrifiadau. Mae'n meddwl i wneud chi'n meddwl i'r ddaeth cyfrifiadau a'r wordd, is that, well, I can't test something that's not built, I don't know what it is yet, so I can't test it. And BDD just kind of changes the words that you use, it seeks to re-evaluate and look at the language that's used and the vocabulary that's used along with this idea of building systems. So we don't talk about tests, we talk about behaviour. We don't talk about test cases, their specifications or scenarios. And we just look at, okay, well don't consider the test because if you're struggling with writing tests first and I can't test what's not built yet, well don't think of it as a test. Just describe how you want the system to behave, what do you want it to do? And that's a very basic level, all it does. But once you put that approach towards people, they kind of take to it a little bit more and it's just a little easier to get to grips with, oh I can actually start thinking about the design of my system before I build it, because that's what ultimately we're doing with behaviour-driven development. We're not trying to test the system, we're trying to design a system that does the right things according to the behaviour we've specified. So another sort of TLDR way of putting it is, I'm starting with the TLDR so you can all go to sleep after this. TDD is building the thing right, it's making sure you're using best practices, it's making sure you're using the right design patterns and building decoupled and modular code and all that side of things, which is cool. But BDD is about making sure that you've built the right thing because it's all very well having the most well-architected piece of code in the world that's fully decoupled and you can do whatever you want with it and it's really awesome and performant and amazing, but if it doesn't do the job that you need it to do, it's useless and it's worthless. So with TDD, developers are often the core focus of it, it's about us as developers building good software but using the right patterns and practices and that side of things, making sure the code works under the surface. Behaviour-driven development looks to take us out of that little bubble that we like to live in as developers where we put our headphones on and we say no to the outside world and we just sit writing code and it seeks to bring us into a world where we look at what other people are invested in this system, what other stakeholders have I got? I don't mean in terms of monetary investment, I mean in terms of who's got an interest in this project succeeding. Me as a developer, I have an interest in it. QA, they have an interest in it. The business analyst or the domain expert or the product owner, they have an interest in it. And if, say, you're building a point of sale system for the front of a shop as tempting as it would be to be given a load of money to build this and you go off and you build it and you come back, the most important person in that example to speak to would be the person who works the till every day because they can tell you the things that go wrong with the system and they can tell you what they need it to do when a parent comes up to them with their kid who's crying and they just need to get through the till as quick as possible but they're searching for where the right button is because they don't know it's not obvious. So it seeks to bring us out of this little developer bubble we have and take us into a world where actually there's other people involved in this process of building software, let's talk to them. We'll be looking at scenario BDD as an example today and basically we're going to specify that any test in a system shouldn't be considered a test, it should be described in terms of the desired behaviour of that particular thing. The desired behaviour comes from requirements set by the business but it's not always purely what they want, it's a collaborative effort. There's a number of types of BDD scenarios, one of them, spec BDD is another one which if you've used a tool or heard of a tool like PHP spec, that's more along those lines, we'll be going along with scenario or story BDD for this particular talk. So BDD was come up with by Dan North and it's described, read this, you've got 10 seconds, there'll be a pop quiz at the end of the talk. BDD is a second generation outside in pool based, multiple stakeholder, multiple scale, height, automation, agile methodology. We've got a number of buzzwords here, pool based, stakeholders, scale and agile, we like buzzwords. I'm going to pick out a few key points from this, it's second generation in that it didn't seek to completely get rid of TDD but it evolved from it, it looked at the lessons learned in TDD and kind of went okay, I can improve upon these, we can make this a better process for everyone involved. People focusing on TDD kind of focus on the how, how is something built? But they lose sight of the most important question as far as I'm concerned is software development, which is why? Why am I building this, what am I trying to achieve? Because you've told me what to build, but that doesn't tell me what your goals are for this particular thing. If you tell me about your goals and your achievements and what you want to achieve, then we can work together to create a system that actually achieves that rather than just you telling me what to do, I go away and do it. And these come from it being a multiple stakeholder based methodology. It works best when you do get multiple stakeholders involved and I don't just mean getting your team of developers and sitting down and doing it, unless you're all the most important part of that particular part of the system. I mean talking to other areas of the business that are involved, that's where the best things come from. And it works quite nicely as an agile methodology because it works really well in short iterations. The shorter feedback loops you have, the better this particular thing works. So I'm going to sort of hark on this point of multiple stakeholders quite a lot. They're absolutely crucial for behaviour-driven development without them. Quite frankly, you're not doing behaviour-driven development. But through these conversations you have, you end up doing things like establishing a common language with each other. You will start referring to things by the same terms, which goes on to improve your code, because if you use it to drive that development, suddenly you realise, I'm using these business terms in my code, which is the sort of gateway to domain-driven design effectively. So with these stakeholders, we'll end up having things like technical people, and they'll live in their little bubble. Then we have users of the system, they'll live in their little bubble. We'll have the domain experts and they'll live in their little bubble. Each of these groups have different ideas of what they actually want. No one group has the best idea. The best idea comes from all of you. Through talking through these things that you want, having the conversations, that's where the good stuff comes from. In reality, it's not necessarily always about the people. It's about what the technical people think they want. That's a key part, what they think they want, because what they think they want and what they actually want. Two very different things. It's what the users of the system think they want, and it's what the business thinks they want. Again, that's where the good stuff comes. When you get people in a room talking about what they think they want, suddenly they start realising, there's another aspect to this that I haven't considered. In the end, that overlap in the centre of the Venn diagram where everyone's ideas come together, that's where the good stuff lies. With behaviour-driven development, conversations are the single most important part of BDD. It's a collaborative process. These conversations with other people form that starting point for collaboration where you sit down, you talk through what the process is, what you need to achieve, and then just through, honestly, natural discussion is what it ends up evolving into. You realise, okay, I'm starting to get an idea of what's going on. Now, the order you really want to do this is you want to have these conversations first, and then when you're having them, you want to start capturing them, writing them down, and then you want to leave this to last, but the automating conversations is the part the developers love jumping to, because we love automating things. We'll jump to automating conversations, stick them all in, feature files in Gherkin, run them in Beham, and be like, cool. But if you haven't captured those conversations, you're not automating conversations. You're automating what you want as a developer, which is not the same thing. So you need to have these conversations before you start writing code in your system. Don't do it too far before. Don't do it months and months in advance. But definitely before you start writing code, in reality, before you really start thinking about the code. Because behaviour-driven development focuses on the business requirements and what everyone wants, it doesn't care how it's implemented. It doesn't care what piece of code you're writing to achieve this. It looks to focus on, okay, what's the goal here? What are we all working towards? Then, when you've had them, then you can start capturing them and we can use them to drive development. From these conversations, you'll end up writing them in a format called Gherkin. I will go through that in a little bit. But when you're talking through systems with people, you'll realise that everyone starts talking in examples. They'll give you examples of what they've encountered. They relate these conversations they're having about a system to their real-world experiences. They'll start describing things in a way that you think, okay, I can see that's actually happened to them. That's something they've actually encountered. Liz Keogh put it really, really nicely. Ultimately, BDD is the art of using examples in conversation to illustrate behaviour. It's about having these conversations using those examples that you're picking up with the people you're talking to, and using those to illustrate the behaviour in your system and how you want it to work. Unfortunately, if you became a programmer because you wanted to hide in a dark room on your own, not talk to anyone and write code all day, BDD is not going to work for you. But I would argue that BDD ultimately builds better software. Examples are completely essential to what we're doing. As Liz mentioned, that's the art of BDD. Examples remove a lot of ambiguity in systems. When you're talking as a developer, you often think in terms of rules. We like rules, we like structure, we like, okay, give me a defined set of things to work with. But rules can be incredibly ambiguous once you dig a little bit deeper. On the surface, it might make sense. Or without even realising it, you'll start making assumptions on the rules you've been given. For example, if you're working and building a point of sale system in a shop, and they say, okay, students in this shop get a 10% discount. And you go, cool, okay. You go away and build a system that gives students a 10% discount in the store. And then a student turns up and looks to buy an item that's already 50% off. What does it do? Does the 50% discount override the 10%? Do they get it for a further 10% off? If it was 10 pounds, it's now five. Do they get it for £4.50? If you don't seek to clarify these things with actual examples of what's happened, you look at rules, you implement them, and then there's a 50-50 chance that you'll be wrong. But my experience both ways are wrong often. Because business requirements are very different than just 50-50. So when you talk through a system in examples, it boils down to just asking. When you're having a conversation, if you hear a rule mentioned to you, it's kind of having that internal switch that goes, okay, I need to explore that a little further. I can't just take this at face value. And the question I always get asked is, well, how do I do that? How do I get examples from people? Let me just cut them ahead. Five words. And all you need to ask for someone is, can I have an example? And when they say to you, I want a 10% discount, you say to them, can I have an example? And someone who's got that real-world experience with the system will immediately go back into their internal memory and be like, right, I've encountered this before, this is what happened and this is what should have happened. And they'll start talking you through it. And in reality, you'll end up with more than one example. But just taking those rules at face value and accepting those as gospel, that's not the way this works, that's not the way this works. I'm going to give you a little more clarification through, don't focus on rules, focus on the human interaction and the real-world conversations. So as developers, we like doing things with languages. This is a lot of sort of meat-space talking right now. So we want to start looking at, how can I start putting this in place? What can I do as a developer to take these conversations I'm having, work with them, and actually start improving the way I'm working? Just really quick, I can't really see, shout out and wave, if you've used Behat before. I see a few hands waving. Whose first experience with Behat was writing, given I am on this page, when I click this button, this thing is on the page and sees that, yeah? Okay. Gerkin is a way to describe that sort of interaction with the system. And a lot of people's first encounter with it is, oh cool, I can drive a browser with this. And that's not wrong. I did, but that's the way a lot of us come to first approach things. I did. I came to it and I was like, oh cool, I can automate browsers with this and do it that way. And then I found out that that's using Behat as a testing tool, but it's not using it for behaviour-driven development. And they are two different things. So when we're capturing these conversations, we write them in a format called Gerkin. It's a domain-specific language that focuses on a few keywords and phrases to be able to illustrate the behaviour that we're describing. And the good thing about Gerkin is it's human-readable. It works for stakeholders that are not technical. We as developers look at our unit tests and we think, I can read that. That's really simple. That's fairly straightforward. You show it to a business analyst, product owner, someone who's non-technical, and all they see is just the green text from the matrix and they switch off. So as readable as it is to us, it doesn't work. So Gerkin is a really nice format that's literally just human-readable language that they can read through and agree that, yeah, that's how this should work. That's what this should do. That's describing the value that I'm trying to achieve. Tools that work with it can include multilingual support as well, which is quite nice. If you're working with cross-language barrier teams, it can be quite nice for that as well. If you're a pirate, good job. Good job. You got support in this as well. So we're including pirates if we need to for building, I don't know, the latest software for swashbuckling. Good work. But more specifically, Gerkin is a keyword-based language. I'll go through the keywords in a little bit. And it's line-oriented, so each line has new meaning in Gerkin. So it's a bit like Yamle in the line-based way. Importantly, though, Gerkin is documentation for your system. Who here writes documentation for their system explicitly? Who here likes writing documentation for their system explicitly? A few hands. The problem with documentation is, pretty much as soon as you've written it, it's out of date, and you have to go back and you keep it updated. That proves to be a lot of work. With Gerkin, because you're describing the value that this piece of software is achieving, you can kind of document what the system is meant to be doing just by having these files that you're using for your development and your automation. And because of that, if the feature changes or the goal changes, the feature file should change, and therefore that's updated just through the process of development. It's not an explicit documentation test. And as I've mentioned, Gerkin allows us automation within a system, which is great because developers, we love automation. We will automate absolutely anything if we can. Hey, boss, I spent the past week automating this task. It takes five minutes. Yeah, well, given a few years, I'll get my time back. We've all done it. I've mentioned it briefly before. With Gerkin, just because you're writing Gerkin in your systems, it doesn't mean you're doing behaviour-driven development. It just means you're using Gerkin as a testing tool. So, move on to the subject of features. Within a system, we describe features of the application. This is what a particular thing should do. And in agile world, they are often considered user stories. A journey through the system and how it should work, what the user expects to happen. A few key tips. This isn't going to be a novel writing class, don't worry. But when you're writing stories, don't start with once upon a time. But be descriptive. When we're talking through these examples, don't be vague. Don't be overly when a thing happens. Be concrete in the examples that you're working with. But that comes through using real-world examples in what it is you're building. Those come from the conversations you're having. Describe the business logic and the business value that you're working with here. Don't describe how it's implemented. That doesn't matter. And you want to give context to what you're doing. Often, the context comes in the form of why. Why am I doing this? If I'm told to do something, it's very difficult for me to do it unless I know why I'm doing it. I want meaning behind the work that I'm doing. And if I know that meaning, then I'm more able to be able to potentially offer an alternative route that might achieve that goal a little bit better. It might not, but we don't know unless we talk about it. When you're writing your features, features go in a .feature file in a directory that you can specify yourself or a default route of the project features directory. You want a single feature per file. You can group them in folders. You can organize them however you want. But you want to stick to a single feature per file because that allows you to make sure that it's more focused on what it's doing. Within this, you will probably use multiple of the things within it, but one feature, that's the way it works. I've seen this sort of format of describing something before. As a role, I want feature so that benefit. Yeah. This is how a lot of feature files get written. As a customer in a shop, I want to be able to buy a gift so that I have a gift for my partner's birthday. However it might be. The problem with this particular format I've found as a developer is we look at as a role and we say, okay, cool. I know who I'm working with here. I want feature, I'll go and build it. And then we walk off and we go and build the feature. And we've missed the most important part of all of this, which is the benefit we're trying to achieve. That's the goal we're trying to achieve here. So an alternative way to word this is something that Liz Keogh came up with. And it's just a very simple change. But you say, in order to achieve value, as a role, I want feature. You put the value that you're trying to achieve first, you can't ignore it then. It's a really simple thing, but subconsciously us developers will switch off on the previous example. This one, you put it front and centre, you can't ignore it then. Within a feature, we'll end up working with something called scenarios. Now, a scenario describes a situation, an example in your system. As I've mentioned before, in the conversational side of it, examples are absolutely essential to what we do. They're the art of behaviour-driven development. Without them, we're not really going to be able to build the best software. Within our system, features can have multiple scenarios. So a single feature, per file, but a feature can have multiple ways of describing examples that that feature may work. So if we were doing login on a site, for example, authentication, we might have separate files for login, logout, register, forgotten password, but within that, we might have feature files that describe logging in with correct credentials, logging in with incorrect credentials, logging in on a disabled account, for example. Those are different examples of how the login feature could work, but they can all live within the same file. And then with scenarios, the way we describe this, because this is line-based, scenarios have steps, and the step describes what actually happens on each execution phase of the gherkin file. Steps rely on a few important keywords. The first is given. In testing, the phrase that's often used is a range actor-sir or assemble actor-sir. And the first part of any scenario specification or test is to put yourself in a known state. What world am I working in here? Because if I don't have a known state for this example every single time, I can't necessarily assert that the behavior is going to be the same. I can't tell you that the behavior is going to be the same the next time I run it, if I'm not working from the same point in my system. That's what given does. It puts us in a known state to work with. We then use when to describe the key action that we're actually implementing within our system. What's the particularly key business rule or piece of business value that we're trying to achieve here? What are we trying to do? In order to observe the outcome of the behavior that we're testing, we use then, which describes something that we can observe that basically tells us that the system has done what it should do. Is my behavior correct based on being in a known state and then doing something with it? We might have a scenario that reads that even I have a large t-shirt product when I add a large t-shirt to my basket, then I should have a large t-shirt in my basket. What this has done is a very simple example, but what it does is it says okay, I'm in a known state, I have a t-shirt, there's a t-shirt available. When I add a large t-shirt to my basket, then I should see it in my basket. If we hadn't set the world up with a t-shirt or we hadn't described it, well, how do we know that there's even a t-shirt available for you to put in your basket? If it's not there, you can actually describe what's actually happening. There's a couple of other words to go with it as well. There's and and there's but. They don't do an awful lot, but in terms of the human readable nature of gherkin, they allow a lot of power in what we're trying to get across. Because it's a more human readable language, it's just more natural to use these words in order to build this software. So a sort of larger example might be given I have a large t-shirt product that costs £9.99 and I have an empty basket and I am a tax-exempt customer. That's setting up my world into a known state. What's the situation I'm working with here? When I add a large t-shirt to my basket, that's my action, my thing that I'm performing, then I have a large t-shirt in my basket, and the basket total should be £9.99. But I do not have tax applied to my order. So with these additional words, we can sort of write something that describes the way a system works in human readable language so that ultimately anyone can really get on with. So with the make-up of our feature file, the entire feature is considered whatever's in here. There may be multiple scenarios for the sake of space, I kept it to just one. But this is our feature. Within this, we have our scenario, as a single block here. And then each of these lines acts as a step within the system that describes something that should happen. So I'm going to give you a brief story writing lesson on how I'm doing a good story. Scenario. I can add a product to my basket. Given I'm on the product one page, when I press add to basket, then I will see PlayStation 4 and I will see £250. This works, goes to the website, goes to the right page, presses the button, product gets put in my basket. It's kind of good, right? This is where I started with writing gherkin and B-hat. The way I would look at writing this now, this comes from a very, I know what I'm building, I'm putting this in place, this is what's happening perspective. Which, as an automation tool and a quote testing tool, would work. A better way to describe this would be to go right back to the conversations you're having. This is probably an example of something written without a conversation. When you're talking through the conversation of adding products, they're not going to, the stakeholders you're working with, they're not going to be focused on URLs and buttons and that sort of stuff. They'll pretty much say something in more along the lines of, spacing issue. Given I have a PlayStation 4 that costs £250 when I add the PlayStation 4 to my basket, then I want to have one product in my basket and the basket total will be £250. This is more of a conversational way of writing things. It's come from a natural conversation and it's been captured. This is a better story. Reason being, in the previous example, what happens when that button changes to say add to cart? Product only comes back to you and says we've spent millions on this and they've decided that the word basket just isn't playing well with customers. We reckon we can get a 50% increase in sales if we change it to say add to cart. And you're going, ah, damn. I'm going to go and change all of my feature files to say add to cart instead of add to basket because that's the button it's looking for. This example is one that's written with implementation and it cares about the web because we've got a URL to visit. We've got a button to press. It's more of a UI-based test. We've got this sort of implementation in your feature files. But you can avoid that by having these conversations before you start writing the code. Don't just jump into using gherkin as a way to automate tests in a really quick way. If you're still struggling with thinking about implementation even when you're having these conversations, consider what would happen if I'm trying to build this feature in these scenarios I've written. What would happen if I tried to run this on the command line or through a mobile app? Well, a mobile app doesn't have URLs. It has view layers and controllers and actions. Press add to basket. There might be a button available for that. That's fine, but that might work. Fundamentally, it doesn't describe a mobile app. It describes a web interface. Whereas if we go back to this example, this doesn't describe any interface. It doesn't care how it's run. It could be done via the command line. It could be done via a mobile app, a web interface. It describes you walking into a brick and mortar store and actually performing this action. That's what you're trying to capture here. How do us developers work with it? We've gone from the meet space talking conversations and collaboration. We've looked at how we can start putting these things in place into capturing these conversations, but how do we actually start going through the process of automating this? With BDD tools, we have something known as a step definition. Step definitions match a step within your feature file to a piece of code that can be executed under the surface. In this example, we will say, given I have a large t-shirt product, and then for PHP and BHAP, using annotations, it will say, given I have a product. When you run it through this particular file under the surface, BHAP matches this and executes the code within this block. That's kind of the starting point for everything within BHAP. We then have arguments. What arguments allow us to do is pass data from feature files into our step definitions in order to work with them. Effectively, under the surface, this is called Pernip syntax with the colon product. There's a big obsession with vegetables in Gherkin Cucumber land. What it does is it will say anything that matches either a regex pattern or this particular pattern gets put into this product parameter for my step definition and then executed through. In some tools and in BHAP in particular, they have what's known as a suite and a profile suite and multiple profiles. What these allow you to do is to take those step definitions, or those feature files, sorry, and you can run the same feature file against multiple implementations. Under the surface, you could execute two different pieces of code based on that same feature file. They effectively allow you to test features with different configurations under the surface. You could have a suite that uses the same feature files as every other suite. Or you could say some suites use different feature files because they're not particularly applicable to this testing suite that this BDD suite we're working with. With suites and tags, as I'll get on to it a little bit, you can use the same feature file to test different implementations of your system. What this allows you to do is have a UI suite on the surface that uses different step definitions and different code than a service or a domain or a lower level suite within your application. We could say this is my domain level suite. I'm just testing objects here. When I add the PlayStation 4 to the basket, all it does under the surface is it calls an ad product method on the basket object we've got. That's cool. It means we're just testing objects in the way the system works under the surface. But then if we did want to run this test through a UI, we could load a different step definition that says, well, actually now I've got the same step within my feature file. I've got the same step definition annotation that matches, but this would be in a different file loaded in a different context within Behow, which is a world that you're working in effectively. This one, instead of just calling an ad product method on a basket object, is visiting a web page and pressing a button that says add to basket. We're still doing that UI-level testing, but we're not describing it within our feature file. What this means is that with this example we can change our implementation without changing the documented business values. That's where the power in all this lies because implementation changes a lot more frequently than business rules. It's just the way it is. It's always the way it's been. Business rules, they do change. They're not immutable, they do change. But it's much more likely that you're told to change the implementation and don't have this particular button. That can change quite a lot. But the actual process of adding a product to your basket, that's probably not going to change all that much for any commerce company, for example. That's going to be one of the core pieces of their application. I'm really quickly going to jump over to a demo that will likely cause issues. We'll see. OK. This is a feature file that I have. This is just within PHP storm. But similar to the examples I've been using already, to keep us sort of going on that theme of buying products, product basket. So that I can buy gifts for friends as a customer, I need to be able to put products into a basket. Firstly, I've described what's the value I'm trying to achieve here. I know that I'm trying to do it for friends. I'm buying products for friends. As a customer, I need to be able to do it for friends. Now, the area between the feature file and the first scenario is kind of like a free form text area. You can pretty much do whatever you want. I've put some rules in here. Now, those aren't the be all and end all. Rules don't describe everything within the system. This is just a kind of almost like a notepad to remind me what I'm working with, along with the examples I'm working with. I mentioned earlier that rules are very ambiguous, but there's a system in the world you're working within is. This is just comments about things you could do further if you do go and look at the code. But we now have a scenario here. I'm buying a single product. Given there's a PlayStation 4, which costs £250, when I add the PlayStation 4 to the basket, then I should have one product in the basket and the overall basket price should be £250. If we look at the overall basket price there, that matches our rules that the delivery is free on orders over £100. This order is over £100, so the total price should be £250. Next example I have is I'm putting multiple products into my basket. I have two products, I add them to the basket. I should have two products in the basket and the overall basket price should be £65. My rules state that anything below £100 costs £10 delivery, so £45 plus £10 is £55 plus an additional £10 delivery leaves me with £65 for my total price. What you may also notice as well is we've got these two tags at the top here, Domain and WebUI. In Behat, if you, above a scenario if you use an app symbol, what they'll do is it will tag that scenario with a particular tag. It's almost like categorising them. And I've got behind the scenes some configuration that says okay, I'm going to run all my scenarios that are tagged with app domain through one set of contexts, one set of step definitions. I'm going to run that through a different set of step definitions. And finally down here, I have one that's tagged JavaScript as well because for whatever reason this is a particular piece of functionality on the site that I need to run through Selenium. I need to run it through a full browser so I've got JavaScript. I wouldn't recommend doing that with all your tests because they will be really slow. Now, if I go and look at the code that's driving these under the surface, there's a configuration file with B-hat and you use it to configure your different suites. So I have a domain suite. I have a work in progress suite if I've written some features that are still a work in progress, they don't need to be executed. I can ignore them. In my domain suite up here, I've tagged it with okay, look at everything that's got a domain tag on it. I don't want anything that's got work in progress. The tilled in B-hat is not basically. I don't want anything that's tagged in progress. Anything tagged domain, we're good to work with on that one. Web UI, I want everything that's tagged Web UI and, again, not work in progress. I don't want JavaScript as well. I'll leave those for a separate test. And then I have a JavaScript suite that looks for everything that's tagged with JavaScript. So I've got multiple different ways of executing this code in my system. If I look at my given step, if you're using PHP storm by the way, it's got really nice B-hat support where you can command click on things that you want to do. I've got two contexts here. I've got a basket domain context and a Web UI context. As I mentioned before, context is the way you kind of describe the world within a system and how the world works and what environment am I in here. So within my domain context, I'm kind of working with the domain level code under the surface. With my Web UI context, I've now got the concept of a Web UI to go through. I've got a network stack or I've got a fuller application to work with. So if I look at my domain context, very similar to the example, when I add the product to the basket, I call an add product method on a basket object. If I look through the code under the surface, this is, don't write this code in production, this is just really simplistic examples. But effectively, my basket object has just got an array attribute on it of products, I add the product to it and every time you add a product to the basket, just increment the product price by the price of the product. That's the way my context for that works. So I can run that domain. If I run my domain level suite, what this will do under the surface, this is just a script that goes into Docker and runs some tests for me. To make that a bit bigger. What it's done is it's gone through and much like a lot of other automated tools, gives you nice green stuff when stuff passes, red stuff if stuff doesn't pass. But it's picked up the three scenarios I have that are tagged at domain and it's run those for me. And it's told me, okay, these let me just do so you can see it. These three scenarios have passed, I executed 13 steps and it happened in 0.08 seconds which is pretty quick, but that's because under the surface this is just testing objects talking together. This is domain level code just talking to each other. There's no network stat going through this. If I look at the web UI context that I've got, now we start getting a bit more higher level. We're not dealing with objects under the surface, we're actually dealing with, well I've got a product page here, that's a abstracted way of just effectively talking to a URL on a system. And I'm opening the page with the product ID that I want to get. And then I'm calling this add to basket method which under the surface just presses the button that's got an ID or a class or anything that it can match with add to basket. So now we're getting into the, oh look, I'm actually doing the UI tests that we could have described earlier but I'm not doing it through the feature files that I'm working with, I'm doing it via the context under the surface that I'm working with. So now, when I run my suite instead with my web UI what you'll see is it will pick up two scenarios instead. It's picked up both the ones that were tagged at domain in that web UI if we quickly go back to the configuration here. You'll see that my web UI, I said I didn't want anything that was tagged JavaScript in my feature file, I've got three scenarios one of which is tagged web UI but it's tagged JavaScript so don't include that one, just ignore that I want to run this in a separate configuration. What you'll notice is that it's done these two scenarios but it's taken a bit longer under the surface it's calling my symphony application and passing a request through the kernel this isn't using a full network stack it's not going through a connection to it because I've got an extension installed that means I can talk directly to my application but a lot of the time you might end up going through a full network stack which is just going to increase the time it takes to run these scenarios even further and then finally I have a JavaScript tag. This effectively is using the same context as the web UI because it's driving a browser be under the surface uses an engine called mink which is used to talk to a number of different ways of interactive browsers so it can use a browser that's like it doesn't use phantom.js anymore because that's gone I think but you can drive Selenium with it, you can drive headless PHP browsers there's a lot of number of really fast browsers it can drive when I tag it with that JavaScript mink is told okay now you need to go and talk to Selenium and in reality Selenium is at the minute it'll be running in a Docker container this is just a Docker container that runs Selenium and nothing else so that I can show you that this isn't just all scripted niceness and I'm making it pass just for the sake of it it does actually do something so if I run my I'm going to run my JavaScript test and then switch to my Selenium viewer you'll see effectively a Chrome browser window pop open a couple of pages load really quick and then it'll disappear behind the surface but that's because mink behind the scenes is being told okay now you need to talk to Selenium go away and drive that and we'll do that proper full-on browser popped up it's gone it was pretty quick thanks to some Docker magic what you'll also see is that this is only run one scenario it's used three steps but it's only run one scenario and it's actually taken 1.67 seconds which might not seem like a lot of time but this is A, a really simple test B, not a very big system that's doing an awful lot and C, this is one of potentially thousands of tests or examples or scenarios that you may have within a system so when people sort of look at the their first interaction with BHAT is to just jump in and automate a browser yes it works but you're using BHAT as an automation tool you're not using it as a behaviour driven development tool so in summary the way I can sort of wrap this up BDD is about collaboration through conversation with concrete examples and the way you're working with those three things if you collaborate and you have those conversations and you come up with those concrete examples in the system you're 90% of the way there the automation stuff that's just an implementation detail that's just how you put it within your system but if you're talking to people even if you're not capturing those conversations you're already getting an idea of what the system should be doing outside of your little developer bubble you want your stories told by real world examples you want to use those real world examples from people that have an investment in your system that you're building you want those user stories to be your requirements for the system because those user stories are really quite important in the grand scheme of building this piece of software you want to involve multiple stakeholders when you're building the system because no single idea is the best idea it's a collaboration and it's an effort between multiple people a little bit of give and take you give a bit of your space in what you think you want to actually know that's a bit more reasonable when we've spoken through this you want to write your features before you've written code and you want to write them without implementation but that's a lot easier to do when you're having these discussions before writing code at the beginning of all this you're going to have a conversation you're going to capture that conversation in the middle of it you'll do the developer stuff that we all like which is all automating and implementing that conversation the code side of things but you can't have a middle without a beginning to your story and in the end of your story pretty much you'll have happy stakeholders and pretty well built software you'll have software that does what it actually needs to do software that achieves the business goals that have been set out and you get the nice warm fuzzies inside the slides will be online they already are there's links and reading available if you do want to look at anything thank you for listening find it on joined in there