 Can everybody hear me? Can everybody understand me? Halfway there then. My name is Fred Heath. See what I've done there. James Bond style. You can call me Fred. I came all the way from Cardiff, in sunny Wales in the UK, to talk about BDD. Does everybody here know what BDD stands for? What it means? Yeah, I know. That's a very good point, actually. Breakfast-driven development. Yeah, BDD stands for behaviour-driven development. And last time we asked at a conference, someone said, someone said, it's body dysmorphic disorder. Which I suppose is technically true, if you're at a medical conference, but not really for a developer conference. I would also have accepted bug-driven development. I would have accepted bug-driven development. I would have accepted bug-driven development. I would have accepted bug-driven development. I would also have accepted bug-driven development. No, just kidding. That's what I used to do, bug-driven development. And now we just do behaviour-driven development. So we eliminate the bugs, as it is. Basically, I've been practicing BDD now for the last four years, give or take. I'll be honest with you. The first couple of years were a real pain to me. They were very frustrating. I used to have to rewrite my features all the time. I used to have to maintain the features, spend a lot of time and effort. I used to be brittle, I used to break all the time. So it took me a couple of years just to get BDD right. And eventually now, I think I'm at a stage where I can apply BDD at a project and reap the huge benefits. And that's what I'm really here to talk to you about. Is to share the lessons that I've learnt and to avoid the mistakes that I've made. So we're going to get BDD right. So basically, I'm here to spread the BDD love out to you. Can you feel it? Can you feel the BDD love? It's originally the first throw there. Now the back. Can you feel the BDD love coming up? It's just the air conditioning. The BDD love hasn't reached you yet. So just out of interest, just being curious, how many people here have actually used BDD to actually use BDD on a daily basis? Can you raise your hands up? Okay, quite a few then. Quite a few. Out of you raise your hands, how many would you say that you're happy with BDD and you feel that you're getting 100% out of it? Can you raise your hands please? Okay, that's considerably less. Considerably less. And that's natural actually. BDD takes time to master. It takes time to get it right. You learn from your mistakes and you correct them and you move on. And to the people who didn't put their hands up, I say don't give up, don't get frustrated. Just persevere and it will pay off in a huge way in the end. So let's talk about BDD more. Right, what we'll talk about is we'll start with a quick introduction to BDD. Quite a lot of you haven't done it or don't know what it is all about. And then we'll start talking about how to do it properly. What we'll get started, how to define our actors, how to drive behaviour and how to get our features right. And that's pretty important getting our features right because the features are like the basis of a system. If you get your features right then you're halfway there. Getting your features wrong then everything else will just fall apart further on the line, just a matter of time really. And I know because I've been there. OK. Right, we can visualise the development cycle as a kind of a circle or as I call it an onion. And in the centre of the onion we have the development team. The developers, us and we do this software. And in the middle layer of the onion we have the testing team and the QA team. And on the outer layers we have the stakeholders. We have our users system integration if you're doing Scrum you have your product owners. And the way it works is a bit like that. The development team makes the software and they push it out to the testing team and the testing team say yeah that's brilliant, great and they push it out to the stakeholders to the users. I can see some people smiling up there and I think it's not quite right. In real life it doesn't really happen that's just a theory. So what really happens is this. We push on software out to the testing team, the QA. QA say it doesn't behave exactly the way we want it to behave so understand it back to us. We correct a particular behaviour and we push it back to the QA team. So that bit is now working behaving correctly but this other bit is not quite right. It doesn't behave the way we want it to. So we send it back to us. So we go back and forth a few times. We go this testing development loop a few times. Eventually we get it right and we push the software out and release the software to the users or the product owner or whoever. I can hear you thinking what's wrong with that. Surely it produces working software at the end of the day. So what's wrong with that? Well, to answer this question we have to think about toast. Does everybody here love toast? Toast with bread? Butter, jam, yum, yum, yum. Yeah. Hands up if you like toast. Cool, quite a few of us here. I love toast myself and my wife loves toast. And we have this little ritual okay picture didn't come up, never mind. We have this little ritual between us where every other weekend I make breakfast in bed for my wife. So I want to make breakfast in bed I don't mean actually make the breakfast in bed in the kitchen and I put it on a tray and take it upstairs to the bed, right? And we think with my wife she's got very high standards she's got very, very peculiar taste and when she married me, right? Brains and beauty. Now I'm just kidding, of course I've got no brains at all. So she wants a toast just perfect. Yeah? Not too soft but not too crispy either. Not too white and not too brown. But it also depends on the bread as well. Sometimes you have the seeded bread that one of the seeds in and with that bread she doesn't really mind if she gets the bread a bit she's very well done. But with a standard bread she wants it very well done but not too well done. Do you know what I mean? She was just right, just perfect. So what normally happens I will make the toast for her I'm putting a tray with some scrambled eggs and some butter and jam and what have you I'll take it upstairs and she'll say oh Fred you burned it again. It's black so I'll take it upstairs again I'll get my button knife out I'll take it upstairs again and sometimes she will say oh Fred but you scraped it too hard and I was like all gone so I'll have to go back in the kitchen and make another toast and eventually I get it right but I'm thinking why can't I make the toast perfect the first time why can't I just know exactly how my wife likes each particular type of bread so then I can actually get the toast right every single time without having this back and forth all the time kitchen, bedroom, back and forth yeah so that's I think I wonder about the software development as well why do we have this back and forth what can we get software right first time just like we can make toast right first time if we know exactly what we're trying to achieve and that's what behaviour development comes into play that's the problem it's trying to address so if we look at our onion from a BDD point of view it's slightly different so the first thing you can see is that the teams in the development organisation have changed they've expanded a bit they've stretched out so now the development team is no longer in the centre it just stretches out of the middle layer and the testing, the QA team stretches out into the outer layer as well and the same for the stakeholders they're not just on the outer layer they come to the middle layer so they tend to overlap the roles in the development organisation and that's very important for BDD to work right you need to have overlapping roles you can't just be a developer and sit there in the middle and once we give you a test to write a code for you've got to participate you've got to sit there with the people who write the test and sit on with them and write with them and the same goes for the stakeholders, the users or the product owners they need to actually get involved in writing how they expect the system to behave and we'll talk more about that in a minute but first let's see how BDD works so we started the development started from the inside out so we started developing software at the centre we moved to the middle layer and then to the outer layer the behaviour of development is different it's an outside in development so we start from the stakeholders we start from the users, the product owners we sit on with them and we write some features what's a feature a feature is just a behaviour that we expect from our system and a feature is written in natural language what's natural language well to me in English to you might be French or Flemish or German or whatever but the whole point of the feature is written in language that anyone can easily read and the features are meant to be read by anyone if you write a feature that cannot be read by your users or your product owners then it's not a good feature so we're out of features where do we go from there we start writing some step definitions what's a step definition a step definition is just some code that exercises our features so if for example we have a messaging feature then we would have some code and a step definition that goes from the messaging UI and fills in a message body and puts in a header and a recipient and confirms a message has been sent so it's just a code that exercises the feature that's all there is and the final bit in our BDD journey is writing code of course some is going to do it but we're not just writing random code here we're writing code specifically so that the step definitions pass so whatever assertions are made in the step definitions we should provide some code that enables them to pass so if for example of step definitions like I said have a messaging code that goes and send a message and confirms that the message has been sent then we write some code that enables this to happen so what we've done here we started from the behaviour of the system from the features on one hand and we call the code on the other hand so the features the behaviour of the code and the actual code of the system itself are tightly bound the first lesson here was make sure everyone works together so all the roles in the organisations overlap so developers work with testers with the QA, product owners with the users and that's pretty essential for BDD to get it right so what do we bother what do we do BDD first of all you make sure everybody talks the same language features should be read by everyone because everyone talks the same language then everyone understands exactly how the system should behave for its known ambiguity and of course features can serve as documentation if someone asks you how does your system behave just point up to your feature files now most of us in the Ruby world use Cucumber obviously if you come from a Java world there's other tools like JBehave there's Behad for PHP but they all do the same thing all this they run the code against our features through the step definitions and they tell us whether our features, our behaviour is what we wanted to be or not so at any point in development we can actually run Cucumber a nice list of greens and reds and greens are the features that work with scenarios that work and red is what doesn't work so we have this measurable feedback all the time and finally it's a big one we get considerable bug reduction when we release the software to the customer there's a lot less bugs why are there a lot less bugs because we knew exactly what we were building in the first place so we built it in the way that the customer expected there was a study done on TDD a few years back from IBM and a few others if I recall and they found that using TDD reduces bugs about 40-80% compared to non-TDD approaches and BDD is just a TDD approach really use the same principles red, green, refactor and test the front so from my experience actually that number would be even greater with BDD because I've seen considerable reduction in projects that use BDD compared to other approaches but that's just empirical, that's just me okay so enough about the talk enough of the theory let's start doing something with BDD and since we are at our camp what better thing to do really than build our camp so let's build a website call it arcamp.com another website already but just for this afternoon let's build another one okay and the first thing we do the first thing I always do when I start a new system is that I always create a nice big box and what's in the box is our system, our behaviour, our features and what's outside the box is the things that drive this behaviour the things that determine these features and we call these things actors is everyone here from an object oriented or you build background okay does anyone know what an actor is and please don't say Brad Pitt I've heard it before okay got a few people there well an actor traditionally is someone who acts up on a system or is acted up on by a system that's a traditional definition for BDD we need to expand it a little bit expand the term and we need to say an actor is someone or something that dictates behaviour on our system simple as that okay so we have a system this was in the box up there we have an arcamp website who do you think your actor should be or do you think should interact with the website any suggestions in public what you could call a user if you like anyone up sorry sorry the search engine search engine possibly yeah okay that's a possible actor okay let's what about the administrator yeah the guy who maintains the website so let's write that down okay so we have a user user is a person who sits on the from the computer in the room and interacts with the website yeah with the administrator who maintains the website to make sure it's functioning correctly keeps the logs and everything what about the what about the organisers of arcamp don't you think they want some behaviour from the website it's a fair to say the organisers dictate behaviour yeah of course it is so let's put the organisers as well let me ask you a question so we have a data store where we keep all the data for the arcamp website it could be a MySQL database it could be a redis store anything really doesn't really matter now do you think the data store should be an actor or not okay hands up if you think it should be an actor see I'll just trick you there I'll just put my hand up hands up if you think it shouldn't be an actor okay I send a thank what a few people say it shouldn't be an actor the answer is you're both right the answer is it depends if the data store is within our control if we created it we managed it yeah if we have root access to it then it's within our system it's part of our system and it shouldn't be an actor if however the data store is someone else's data store sitting on the cloud somewhere hosted by someone else we can only interact with it through an API but it's external to our system it's not part of our system anymore and it dictates behaviour so we should mark it down as an actor so say for example we use github for our arcamp website so we can I don't know give some code samples for the speakers yeah that github is an actor because when you interact with it through an API it's restricted to us so let's put another actor up here and call him an external API okay right so we've got our actors we've got our system defined what do we got from here something doesn't sit right with me actually looking at this something not quite right can anybody guess what's not quite right with that sorry that's just me being lazy what I don't quite like is the user what's a user user is someone who uses a system what does that mean it doesn't mean much it's very generic isn't it the user system what do they do with it well the way I see it someone who goes for the arcamp website they can do two things with it one is someone like well most people here actually who want to attend the website or attend a conference the second bit is someone who wants to speak at a conference and maybe wants to have been to talk or see who else is speaking so what we can do here we can actually assign these roles to the generic user actor and we can say that the user actor is a delegate and a delegate we can call it that indeed if you like doesn't really matter and this is a person who wants to come to the conference so they go to the website to find out what it's all about and we can have a speaker role a speaker role is someone who wants to speak at a conference and they want to submit a talk for approval okay so what we've done here we've actually specialised our actors we took a generic user actor and we created two specific actors with specific roles and specific demands from the system and that's very important because if we don't do that we can't easily discover behaviour we can't easily write features because a user just too generic we can think of generic things for a user but not specific features and we'll see an example of that in a bit a bit later and we can actually do the same thing with the organisers we can have a salesperson as one of the organisers who might want to sell some tickets for an event after and they could put some address on one of the websites we can have a marketing person yeah true story a couple of years back marketing director where I used to work made us change all the text on our website because he thought it was a bit formal a bit rigid and he wanted to be more cool more street wise and capture younger audience and we did it but that's just an example of someone who's a passive actor ok so lesson for the day for now make sure your actors are specialist it's very difficult to discover behaviour for actors that are generalist specialist your actors ok so we got a system we got a specialist actors where do we go from there the talk is called feature this so when you start writing some features it's very very easy this is some ruby code so all we do for each actor that we have for each specialist actor we ask two questions we ask them what do they expect from the system what does the system expect from them and that gives us a feature ok is that a good feature is that a valid feature how do we know well we need to validate the feature it's solid, it's durable how do we do that for every feature we write a feature story what's a feature story a feature story is just a user story but in a very specific format for that feature so we say that as a specialist actor I want a specific system behaviour so that I can have a tangible benefit ok what's a tangible benefit tangible benefit is a benefit that's measurable that's observable that has an effect has a repercussion let me give an example so we talked about our delegate user our attendee like what does the entity want to do with our website he wants to go to our camp and see what the talks are so we can have a feature and call it conference talk viewer doesn't really matter what we call it as long as it makes sense and we can say that as a delegate I want to see a summary of all the talks so they can decide if I like any or not ok is that a valid feature let's find out ok as a specialist actor, as a delegate that's fine I want some specific system behaviour I want to see a summary of all the talks that's specific enough so that I can see if I like any is that a tangible benefit what does like mean how do you rate like it's very fuzzy what's the effect of liking something I'm not quite sure so that's not a tangible benefit so let's rewrite the feature like that so now we say as a delegate I want to see all the talks so that I can decide whether I want to attend the conference yea that's a massive difference there why is it a massive difference because now we have a tangible benefit and the tangible benefit has very specific outcomes what are the outcomes one, if I like the talks I want to attend the conference what do I do I want to book a ticket really ok so if I don't like the talks if I don't want to attend the conference what do I need to do then and I want to tell the organisers why I'm not attending feedback so I want to say well there are no BDD talks so I won't bother so by having a tangible benefit by having to feature it incorrectly we just discovered two more features for that particular actor right this is an example I came across a few months back actually and I won't name which company but it was like that it was a feature and it was called menu item highlighting and all it was you had a scenario outline scenarios outline by the way are just scenarios with parameters in them if you're not aware so I can pass different values to them but all it did was just make sure that when you clicked on the menu you went to a page the menu entry was highlighted ok simple as that I can see some people blinking I think it's the young ones here ok let me inject something here there was a time and I'm all here there was a time when not every web page was a single page up ok there was a time when we had things called frames and horrible things and menus on the left hand side and all this that's how old I am right and that was one of these actually so you had a menu and clicked on it and a little arrow came up next to the menu the menu was highlighted in some ghastly colour and I looked at this feature on this scenario and I wasn't quite happy with it so I sat down with the guy who wrote it and I said well it doesn't look right to me I said can you actually give me a feature story for this so he tried and he tried and to get a long story short he couldn't and the reason why he couldn't was because he was writing his feature story like that as a user, as a web user when I navigate to any page I click on the menu I want to see the menu highlighted so that I know which page I'm on and I said well I said hold on that doesn't make sense he wants to see what page I'm on he wants to know which page he's on how is that a tangible benefit I mean surely the user knows what page I'm on because one they clicked on the menu link in the first place and two they can read what's on the page so what benefit is it to the web user to have a little arrow and a little highlight and he said well he said really what's happening he said is that a design director wants all the websites for the company to behave in the same way and because we have other websites but when you click on an entry it highlights a menu then we must have the same thing happening on our website too and I said well okay that's fine that's fair enough not a problem but we need to rewrite the feature because it's not a right feature so we rewrote the feature we wrote it like that okay so now we change the actor and we said as a design director I want the site to be navigated consistently with the other sites so that I can maintain a consistent corporate image okay is that a tangible benefit to me no don't care to the web user couldn't care less to a design director is hugely tangible benefit that's the job that's what they pay to do maintain the corporate image okay so we wrote it like that and we left the scenario exactly as it was and the next day one of the QA guys came up to me and he said oh he said I saw the feature for the navigation consistency he said now all our other websites he said they got a little logo on the corner and if you click on it it goes back to the homepage so I think this site should have the same thing really I said okay that's fine can we put the scenario in so we had two scenarios at this point now on that stage I actually left this for a bit I worked on another project for about two three weeks and then I came back to it about three weeks later and I looked at the feature file and we had not two but we had 18 scenarios in there and the reason for that is because people saw the feature and they came up with other ways that consistency was lacking from our website so they added the scenarios in and I was thinking well really doctor bullet here these are 18 scenarios these are 18 bugs that would have come up at some point in the future because when we released the code someone would have seen the website and said well it doesn't behave like the other websites that we have to raise a bug so just by having a feature right written correctly we avoided ourselves the effort and the cost of a huge number of bugs ok so the trick here the tip rather here and you can't see it because it's embedded in an image and the image is not shown for some reason and I apologise for that is that you should always make sure you have your features done right and validate your features against a feature story always have a feature story in your feature make sure that your feature matches a feature story right so let's go back to our delegate actor we have a delegate, a guy who sits on the website almost attend our camp and they like the talks and they want to come to the conference they want to book a ticket so we have a feature called ticket booking and we say as a delegate I want to book a ticket so that I can attend the conference ok is that a value feature yes it is it matches our feature story template feature story template ok so we've got a feature the thing to do now is write a scenario and we normally start with a happy day scenario it's easiest and most frequently encountered scenario so let's write a scenario here ok and the happy day scenario here is a successful booking and given that I go to the booking page I can enter my name and my email and surname and I can click on the ok button and I get a message saying ok you've got a ticket right what's wrong with that can anybody tell me what's wrong with this scenario yeah yes you both spot on really there's actually two things that are wrong with it one like you both said we're talking here about how to do things how to book a ticket now the actor he had the delegate he doesn't really care about putting his name there and saying him over here and clicking that button what they want to do they want to book a ticket as a user as a web user if I go to any website not just our camp and I want to book a ticket for a conference of strictly come dancing I don't really care if I go to put my email there and my surname over there and click that button or somehow to book a ticket that's what I care about and the same goes for the objective the message ticket is reserved appears I don't really care as a user whether I get a message that says hey here's your ticket or whether I get an email with my ticket or whether I get a homing pigeon tapping on my window with a ticket around his little leg it doesn't matter to me as long as I get my ticket that's what matters ok so what happens then if next week my system architect comes into play and he says well listen here he says we decided to change the way we book tickets now and we're going to use google authentication or twitter authentication or something like that what happens to this scenario then it's useless out of a window as we'll check it so this scenario the way it's written is not durable the second thing that's bad with it it's not very easy to read is it so imagine we had instead of four fields imagine we had ten fields we have ten and I enter line and a click line over there and what would we say about features they must be easy to read if you got ten lines of I enter this detail over there and I click on that button over there people aren't going to read it and you need to make sure your features are readable ok so let's rewrite this scenario I write it like that same scenario given that I enter valid credentials then I can book a ticket simple easy to read durable so tip of the day pretend it's an invisible link tip of the day is make sure your features describe the what not the how the how goes in the steps so when we write our feature that says given I enter valid credentials then I get my ticket then in the step definitions we have some code that basically goes to that particular field on the website enters your surname, enters your password clicks on ok that's where the how goes in in the step definitions the features are for the what what the actor wants, what they expect and the actor doesn't care about how we do it he cares about what we do ok it's my final point for the day it's this a good scenario and again it's a real scenario I came across that some time ago it's a new card request and it says given my account it's valid and my session hasn't expired then I have the option to request a new card now I look at that and I think what the hell does it mean I think what's an account well to the person who wrote this to the product owner or the user or the business person probably a bank account I would imagine to me as a developer it's a user account what's a session again a session to me is an SMTP session or a TCPIP session to the person who wrote that it's probably something completely different it's an application level session or a chat session or something the same goes for the card what's a card is it a bank card is it a membership card a loyalty card and that goes back to the first point we made and the first point if you remember was that everybody works together you need to work together if you work together this kind of ambiguity is rise up early so you can clear this up early that doesn't always work though you have a team and you read that and you think what the hell is going on so what I normally do I normally clear ambiguity is in the feature itself so you always have some space between your feature story and your scenarios and you can write basically whatever you like QCAM doesn't mind and what I do there I clarify terms like this so I say by account women such and such TCPIP TCPIP session and whatever and the other thing you can do as well that I try to do now whenever I can is to have a glossary of terms a table where we have all the terms we use in our features and we clarify each and every term so we have a table that has an account and a meaning of the account and if you host your features on an internet wiki or on a tool or a web tool like relish then what you can do you can actually link your terms to your glossary page so you can make sure that people can click on a term and they see the definition of that term and it's extremely useful and it avoids loads of pitfalls okay so the tip here is basically avoid an ambiguous language if you can and if you can't then make sure you clarified you got a glossary of terms or you write something in the feature file itself right so that's the end of my talk for the day basically and just to summarize what I've done with a quick intro to BDD and we talked about how you start writing your features how you discover your system discover your actors and make sure that you know your actors because they're the ones who drive your features and when you write your features just do it right get a nice feature story that describes the what know the how that's a summary of basically the tips and tricks that I want to impart today everybody works together very important know your system and your actors and make sure your actors are specialist you can derive behavioural specialist you can do it easily from generalist actors then every feature must tell a value story and features are about the what's happening not the how's happening but the web definitions what's in the features and finally just make sure you use clear and ambiguous terms okay and that's the end of my talk really and I'll spend five minutes taking some questions