 So I want to I've done this maybe a million times now what I want to do is I want to see what your expectations are and then take it from there because there are many ways to cover this topic and I would like to make it as much interactive as possible. So I'm going to do I'm going to kick start with a small activity that will help me understand what is the audience like and then we will tailor the the 60 minute work demonstration slash presentation in based on that. So this is on behavior driven development and we're going to be writing some code we're going to be doing a demonstration we're also going to be covering some concepts behind what is behavior driven development where it comes from for the purpose of this presentation I would not distinguish between acceptance test driven development and behavior driven development I know Dan North who coined the word behavior driven development might not be very happy with that but for this presentation I do not distinguish between the two that's more of a philosophical discussion right why you don't believe in God kind of a discussion right which we are not going to go there right now. I want to form three groups all right this is not a big audience so we can easily do three groups I want to form three groups and in your groups I want you to tell me what are specific observable results that will tell you the activity that we're going to list after this that is successfully completed so what I want is at the end of ten minutes or five minutes actually what are specific observable results that will tell us that you've completed the activity successfully all right so before I show the activities because then everyone wants to be in the one group which is really the nice group to be in I want to separate them out into three groups and I see that there are a bunch of people from the same company sitting next to each other so now is a good time to separate them into different groups so we'll start there and you're going to say one two three one two three so all the ones will be in one group all the twos will be in other group all the trees will be another group I want to go through this really quick because this is just a warm-up exercise that will help me understand who's in the room all right so we'll start there okay well we'll complete that row and come here it's not that difficult guys quick quick I don't want to spend ten minutes on counting all right so all the ones together in this corner of the room all the twos in this corner of the room number three is going shopping and they have $50 to spend all right so I want you to tell me what are specific observable results that will tell us that you have successfully completed your respective activity group one will tell me what are specific observable results that will tell me that you have successfully watched the movie THX sound system with digital projection right group two going out for a meal group three are going shopping if the group feels too big you can split into two groups right amongst you guys so it is a five-minute exercise it's not a very detailed in-depth philosophical discussion it's a quick discussion somebody in your group should know if not make the necessary assumptions make the necessary assumptions four minutes to go all right thank you guys you can come back and take a seat you who's gonna present from your group who's gonna present back your specific observable results one should all right so you're gonna volunteer so rest of them can sit back in their positions that should be okay for email are you gonna present okay you're gonna present sorry go ahead go ahead please can we have a mic please just use this okay first is movie tickets second is THX certificate THX certified theater okay third one is same digital projection information of theater something like that and third one is our time duration of a movie that we have spent this much time you know in a theater to watch movie okay all right that's good thank you I didn't get your name with the yeah with the representing the first group thank you well go to group number two you can pass the mic please over there so this group went out for a meal and one amongst you was a vegetarian so what are specific observable results that will tell me you have successfully completed that activity okay the list may not be comprehensive but some of the things have been identified whether the location serves vegetarian and non-vegetarian food second is do we actually have the budget for it and what's contribution for it and then time at what time you want to go what would be in morning la snacks or maybe lunch or dinner so we had to find that would be one measurable thing the third one was what's the mode of travel mode of travel mode of travel to all right yeah next and last list of members will be there team members the team members will be there okay cool hold on to that talk we'll go to the third group the gentleman in the red t-shirt a red shirt I think we kept it very simple we we are out shopping and we have to spend $50 so how what are this observable results it's the products that we shop products that you shop okay we have it with us and to prove that it was about $50 or exact $50 we had the receipts which would potentially add up to $50 so we see and the products if possible and if the products were going to ship later then the receipt was surprised but you still have the receipt but not the product yeah okay all right so we have three groups kind of at quite different levels of what we are looking at in terms of specific observable results for this activity right or in other words what people call is acceptance criteria right what is the acceptance criteria so what do you guys feel in general like are we guys doing good on our acceptance criteria how many for this how many for this okay so you're in the right workshop because when you leave you would be doing this all right time for a commercial break my name is Naresh Jain probably you've heard me enough I live in Mumbai I don't act in Bollywood but I've been trying I have few people staying in my building who do but I've not yet got a chance I've started these different conferences and communities I'm an entrepreneur I build I have two startup companies one helps kids learn mental arithmetic another one is a conference marketplace I've worked for these following companies either as a consultant or as an employee and now we have two things we can do from here we could go in and do a deep dive into me showing a demonstration of how I would go about doing this or we could go back and cover some theory around why I did this activity which way would you like guys like to go deep dive forget the theory I'm gonna just take a quick two minute to talk about the activity that we did the objective of the activity is a lot of times when we are given some requirements or some specification saying this needs to be done we as developers as software professionals we immediately kind of start thinking about what are the steps involved how do we break this down and how do we attack the problem right rarely do we ask why the heck with somebody want to do that why the heck somebody wants to go for a movie that too in a digital projection and THX sound system what are they trying to get out of this right what was the goal what was the goal of going for the movie enjoyment but all the things that you talked about in terms of your specific observable results do they have anything to do with enjoyment it makes a difference in terms of your experience but maybe there is more to it right and we didn't really go into the details of that same thing with food you guys were talking about transportation you guys were talking about this what was the purpose of going out for a meal eating out enjoying did any of those things have anything to do with enjoying they seem like all fairly boring stuff right shopping guys were pretty close right what you really care about is the products that you bought but what's interesting is that you know where you going out for your weekly grocery shopping versus where you going out for a sale you know some kind of a sale shopping in one case you would have a laundry list of things that you want to buy and you would verify if you actually bought those things at the end of it and even though you have 50 dollars you want to spend as little money as possible right it's not about spending 50 dollars it's about how can I get everything that I wanted and as little that I can get and if I'm going out for a sale I don't know what I want to buy but I want to get the best deal out in there right so if you think from that perspective ask why try and understand what is the goal you probably will come up with better acceptance criteria or better you know things that will help you validate and drive what you're trying to get at so that's a nutshell of what the stock is all about and I want to actually demonstrate that rather than just talk about it right cool so that's the theory part now we'll do the actual stuff how many people have used a coffee vending machine okay that's good so others of those who have not there are some machines kept out there you can take a break now look at one and come back or we can just continue with the problem so let's imagine this is the and I'm sure you can't really read the text on the screen but it's not supposed to be it's a requirement document it should be fairly detailed right so I have a requirement given by the business saying that I need to build a coffee vending machine and let's assume for a minute that we are the first ever company building a coffee vending machine all right and we have to build a coffee vending machine we have to design the hardware as we go along and we have to figure out what dependencies we have and how we're going to build the system all right there are we've the business has decided it's done some market research and it's figured out that if they charge 35 cents for the coffee they will make enough profits out of it all right and they want to offer four different types of coffees based on the market survey they did and those are the four coffee types that is being listed their black cream sugar and sugar and cream coffees all right we have to decide all the stuff and there are some basic operations that they have discussed in terms of what they think you know accepting money doing a coffee selection and stuff like that so given this problem right like we gave you the last problem how would you attack this problem how would you go about building this coffee vending machine anyone basic operations any other approach who would do a flow chart how the user will use the system so some kind of a use case analysis what would the user do and what is the expected behavior from the system okay anything else what are they doing now and what would it what can we do to make that different to make that better all right great do a prototype and get some early feedback right try to understand how the machine should interact with the user right so do some kind of an interaction design you guys are way smarter than me right I would just start writing code how many people would come and put a coin inside this one person that's good for me right free coffee vending machines so no no coins we need to tell the user what to do right because we are building the first coffee vending machine so we need to tell the user what to do so let's say we have some kind of a display we're not going to have a touch screen at this point right 35 cents it's not going to cut it so we're going to have a simple display which is going to say please select a coffee type how about that right let's say there are four buttons they can be like this they can be like this we are not doing a product design we are just trying to figure out what the interaction will be so we can actually drive the behavior of the system writing some behavioral tests okay so let's say there are four buttons one is for black coffee one is for black coffee with cream one is for black coffee with sugar one is black coffee with sugar and cream all right so we have these four different buttons and let's say the user selects black coffee with sugar all right then what should happen it should tell you what is the amount that you should be inserting into this machine right should say please insert 35 cents so there should be a place for us to insert the 35 cents let's say I put in a dollar or I put in a hundred rupee if it was a 35 rupee coffee right and then what should happen it should do some validation that it's actually a right coin or a right currency because when I was in US I would put steel coins into it to see and get stuff out of it right so we have people like me so we have to do some validation once we do the validation we know that they've inserted actually one dollar and we would say okay please collect your coffee so there should be some place where they can actually get the coffee and some place where they would get the change of 35 cents sorry change of 65 cents in this case all right so they get the change they get the coffee they're happy we are happy what should happen after that go back to the initial states of the when the next person comes in it takes takes out from there right it starts off from there so this is just a very simple happy path case that we've talked through one simple interaction with the system what happens if you're out of coins right I put in one dollar the machine does not have five cents change what should happen so we talk through a few scenarios like this so we understand what the interaction would be all right so if if somebody doesn't have if we don't have five cents change what should we do give the dollar back which is why they don't make engineers make business decisions right don't lose 30 cents for five cents that business right rather give that away yeah so there are other other personas that you would have in the system who you know there are personas for maintaining this machine there are personas you know which would fit into this case where somebody has to fill in the milk somebody has to fill in other things somebody has to make sure the coins are in there so there are other personas but I'm just for one hour session I'm just going to take a very simplistic view all right so we need to quickly discuss through a few scenarios to understand how a particular persona is going to interact with your product right it could be a website it could be something else it could be an iPhone app doesn't matter right so it's important for us to understand what they're trying to do and what is the simplest way to achieve that right and typical projects we spend about a week doing the product discovery phase kind of doing looking at this at a very high level and then we say okay now it's time to hack some code right how many people for that nobody that's good so you in the right session I am gonna write some code at this point because I've understood enough about the system I had to have looked through a few scenarios and I'm gonna switch over and let's just do are people comfortable with the language called gibberish so I'm just creating a simple project here I'm gonna create a test folder over here and that should be pretty much it so I'm gonna start with what is referred to as an acceptance test or a behavioral test that's the first thing I would do ignore all of this stuff because this is pretty much platform agnostic it should not matter so I'm gonna call this acceptance this is everyone able to see this yes okay acceptance test or behavior test I'm gonna later also show you a few other tools like cucumber and things like that where you can do something similar so I'm not going to focus too much on the tool I'm gonna focus more on the technique all right so I've got an acceptance test right so the question to ask is what's the simplest scenario through this product that you would like to exercise what is the simplest thing end to end that somebody can do with this thing with this coffee vending machine insert money get the coffee that's too big a step see the menu select a coffee all interesting things but the problem is they are not end to end they don't really give you any business value right so we want to do something which is end to end but yet simple so we can actually do it and get some early feedback right so what I'm gonna do and to me the simplest thing to do assuming there are bunch of other validations we have done in terms of pricing and stuff like that is I would take the simplest kind of coffee which is black coffee and I would say if I insert the exact change then I should get the black coffee right so what I've done is I've taken the interactions that we discussed the behavior that we expect and I've sliced out something which is end to end but is the simplest path through the system right so I'm gonna say serve black coffee for exact change if I can type all right so let's assume that is a scenario we want to cover all right that's that's simplest scenario we can find that we want to cover now what is the thing that you know the user would do here's the interesting portion of this whole thing right so what would the user do what's the first thing I want to actually step back and say you know I have a brand new machine the first thing I need to do is power it up all right so let's say we say power up and then it should say display please select a coffee type the black forcefully is in your head not in the machine right so you still want the machine to behave as if it would behave normally but you are saying in my head this is the scenario I am covering you don't want to hardcore that in your machine all right you still want to describe what is the behavior of your machine the behavior of the machine is when you power it up it should do all its necessary stuff and then show you a message saying please select a coffee type all right that's an important thing once I have seen this then I can say user selects or I'll tell you this pattern in a minute so select what do I want to select coffee type black and then when I do that it should display what should it display please insert thirty five cents yes can everyone read this gibberish next what should happen next I want to insert what kind of coins it is American coins only right because the specification says that we want to accept American coins we might at this point get a doubt what is American coins right what is the heck American coins are we talking about Brazilian coins are we talking about American coins what is American coins US Canada Brazil so that's some validation we need but for now software is pretty good because we can abstract that concept out and we can say American coins and we can later come back and say what specific American coins we need to deal with right so we want to American coins and we want thirty five cents and then what should happen so I've inserted thirty five we could we could say black coffee but I think it might be overkill or we could also say thanks for your donation at this point right depends how you want to design the system what should be the behavior of the system in this case the behavior of the system as it should display please collect your coffee and if the user collects what coffee coffee type should be black then what should happen the user collected the black coffee the system should go back in its original state so far is everyone with me that's the systems problem we'll get to that right because the system has to do a whole bunch of things here we are not saying what the system should do we are trying to capture what is the behavior that you expect out of the system from a user interaction point of view right so we will go into details where we will flush out how the system will behave and we will see how the design of your system will evolve through this process all right so I've done this at this point I have a failing acceptance test all right I need to get this failing acceptance test of behavioral test to work so I'm going to go ahead and just create some scaffolding to make this work so this is just some scaffolding stuff that I need to do so bear with me for a second what is this this is the expected message right and we're going to say here a cert equals that your expected message is the actual message where how will we get the actual message we'll figure that out later that's not important for now we just want to scape create the frame or scaffolding of this acceptance test so we've got that then it's complaining that hey I don't know what this type black coffee is so we gonna create an enum for now those who are interested in the details can pay attention for others can just look at the approach we are taking so we're saying here we want a coffee type and this should return this and let's go to the next one this should again we want you notice I'm actually building my production code as I'm going through this because I'm also flushing out the design as we're going through this and a lot of this is evolutionary design as we will see in a minute so this is acceptance test it didn't take it because I did it type over here and this should really be sense or coins actually and this should return this the last thing we need to do is this mistake here this is your expected coffee type eclipse is not all that smart right you would think you would just fill that out and here what I want to do again is I want to put an assert equals expected coffee type was actual dispensed coffee alright so far everyone with me so what we've done is we've just gone and framed our test alright this will help us move forward this is one technique to do this I'm going to also show you another technique where we're going to use a different tool where we don't have to get into code so much and we can do it quite nicely but this is what we used to do 10 years ago and I wanted to kind of take you on this decade-long journey of behavior-driven development alright so let's run this bad boy at this point and see what happens as expected right we are saying expected please collect please select a coffee type but was null the famous Java null pointer exception so what do we need to do at this point this is the stage where we need to do a little bit of design thinking right now what actually should happen when you power up the machine if I power up the machine what happens if I power up a laptop what happens right the BIOS kicks in right and the BIOS does whatever it needs to do and then gives control to the operating system to then take over right for a simple coffee vending machine we need a simple controller a software controller that will take control and do its thing right so we're going to get ourselves a controller a new controller where will this new controller come from we don't even have that so we're going to go ahead and create one in our production code again and we gonna store this away for a later point in time so that's convert local variable so we can use it so if you power up basically we are saying the hardware is going to instantiate the controller and give access to the controller and let the controller do whatever it needs to do so when the when the controller is powered up what should happen inside the controller it should do whatever its check and then display the message saying please select a coffee type right that's the expected behavior so let's actually get ourselves a constructor in which when you initialize the machine this is what should happen right so we're saying do some check right now we don't have a case where we don't need to do a check so I don't need to implement anything we need to force ourselves to write a test which will force us to put the check in right so we're saying some check needs to be done and then a message needs to be displayed now again back to design thinking whose responsibility it is to decide what message to display the controller can make that decision right but who would actually display the message the display panel some kind of a display right and how would the controller know where the display is controller doesn't know where the display is right the hardware which instantiated the controller should give the this the controller saying here is the handle to the display right so let's go back to our acceptance test which is essentially our hardware right the acceptance test that we're writing is essentially our hardware and this hardware is going to give you a display but where is it going to get the display from I'm going to teach you a technique which is called self shunting so I'm going to say get me a display oh this is Java of course so we need to write a little more code for this implements display it says hey I've never heard of this guy what do you want me to do I want you to create a display for me in my production code so I've got a display now what I can pass the handle to the display to my controller by simply doing this control one change method signature to give a display so hey I've got a cheap display for myself by self shunting and I'm going to use this display to put the message that I want to put so I'm going to say display dot show please select a coffee type if I can type properly control one again says what do you want me to do with this method create it on the interface and here I come back this guy will complain this is I'm getting into a little more details and if you guys think it's getting too much into details you let me know I'll stop and I'll kind of zoom out and do something else right but this will give you a feel for what this technique is all about this thought actual message is what this message that got displayed over there now if I run my tests it says expected please insert 35 cents but God please select a coffee type so if I actually look at this let's look at the next line it says that hey I've successfully finished the first step of your process now I've moved to the second step of the process so now we will go and flush out some behavior that will help us satisfy the second step in the in our scenario right so when somebody selects actually let me pause at this point so far are you guys with me did you understand why I made all the circus where I had to do all the circus around this right there are better tools to actually do this which will make it much more simpler but I like to take hard shots right it'll help you appreciate how these tools have evolved and what they're trying to do okay so hopefully we will get there we're running a little late so when you select a coffee type what should happen when I press a button on the hardware what should happen notice we are constantly jumping back and forth between designing between implementing between you know deciding what the requirements should be so we're kind of almost doing something that lot of wisdom in the past has said is a bad thing to do right you should have a design phase you should gather all the requirements then you should do the design phase then you should do your low level design then you should go write some code we are saying ah not for me right well this miss makes this whole thing because this seems a lot more easier to make progress and this has many other advantages that we'll talk about in a minute so I want to say when somebody selects something on the prevent somebody presses a button what would the hardware do the hardware would send a signal to the controller saying hey this thing was pressed right so that's exactly what our test would do we've got the controller so it's going to say controller dot user selected or user wants user wants this coffee type control one coffee type so when the user selected a coffee type what do we need to do we need to display the price on the display right we need to show that price on the display how again who will decide what the price should be is it the controller's responsibility not really the hardware right it has to be some other entity's responsibility not the controller's responsibility this is design thinking we are designing as we are going along right so some people even call this the behavior driven design right so we are saying okay we've got a coffee type we need to display the price for it right the display will display the message the controller will decide what needs to do but somebody else should decide what the price should be because that's not the controller's responsibility so at this point you might say well this is getting a little complicated right it's not as simple as I thought because there are a lot more interactions that we are getting here so we might want to step back and look at one of the extreme programming practices of system metaphor how many people have heard of system metaphor one person okay that's good so you're in the right session system metaphor basically is a practice that Ken Beck came up with and he said when we are designing the system as we go along right it can get pretty hairy so to make sure all of us are on the same page can we find a common thing that we all know a metaphor that we all know that we can keep referring to and then use that to drive the design of our system right so we are saying okay we have all these entities and we want to figure out a common way for all of us to be on the same page what's the closest metaphor we can find for this problem right one way to think about it is what are we trying to automate we're trying to automate a small coffee shop which serves coffee right so is this kind of similar can we find a metaphor that can essentially take that and convert it into a software thing so if you go to a small coffee shop right many of you would have been to a small coffee shop who decides the price over there as soon as you enter typically there's a guy sitting on on the table with all these little tickets right and you say hey I want a coffee and the person says it's 35 rupees and gives you a token right so you go to the cashier and you ask the cashier you want a coffee the cashier says how much it is can we use that system metaphor in our problem and say we were gonna you know use that as our metaphor to drive our design so what I need now is a cashier right so I need a cashier so where are we gonna get the cashier from you're gonna give an ad in the newspaper but we can do this in software much easily so we're gonna again cheat the system by using the cell shunting technique I'm gonna say hey give me a cashier I need a cashier so I've got a cashier and then I'm gonna do the same thing over here control one change this and this is a cashier all right let's get this and then we can say amount equals cashier dot what price for this coffee type and then once we got that we can say display dot show please insert sorry it's been a while since I've written Java all right so please display so we're gonna say display dot please insert the amount and let's kind of get this to compile and that's pretty much it except we need to now write a method in our fake cashier which can give us the price in my test can I hard code the price we know the price is 35 cents so I'm gonna just put here 35 cents right let's run this and it says hey no we don't want to see all the time now says please so please collect your delicious coffee but was please insert 35 cents right so we've now moved to the third step of our scenario was that easy yes no good question hold on to that right we will certainly come back and answer that right good question any other question so far so I'll come back to how we do unit testing right we're not doing any unit testing at this point we're just describing the behavior of the system we still have to do a whole bunch of unit tests and when we do we'll talk about that how are we mixing it up I believe we have done a very clean separation over here we have a display which is responsibility is to display stuff we have a controller whose responsibility is to decide what needs to happen right and we have a cashier whose responsibility is to handle all the price-related stuff who needs to oh MVC that's like 17th century so let's move away from that we'll come back to that I want to show complete one scenario then jump to the board and talk about the design and how this design will hold up right and how our behavior is flushed out the design so I want to go ahead and plow through this real quick so when somebody inserts a coin what needs to happen probably need to do some validation but we don't have a scenario right now that helps us that forces us to do the validation so I'm not going to worry about that right we're going to write another scenario that will force us to do the validation right here all I need to day all I need to say to the controller is controller dot accept these coins you've got these coins please accept these coins right create this method so when you get these coins what do you do yes at some point we might need to do validations but we don't need right now because we don't have a failing scenario for that right I know that I've got the exact change now I don't even need to do any validations for the amount right so now I can straight away and say that I've got the money I need to give the coffee I need to serve the coffee let's go back to a system metaphor right what's our system metaphor the small coffee shop so you go to a small coffee shop who gives you the coffee machine no we don't have a machine yet that's what exactly we're trying to do in Bangalore we call that person a thumb be we say thumb be can you get me a coffee right or in Chennai also they say that if you want to be a little more sophisticated then you call that person a barista so barista will serve you a coffee right so we need a barista now where do we get a barista we fake it out so we've got a barista whose responsibility is to make and serve the coffee right and that's again going to be injected into the controller so now the controller has got the barista so now we've done the validation and what do we do at a later point in time when we have changed to be returned that will also happen but right now we don't have a scenario which forces us to return the change so all we need to do right now is we need to say barista dot serve the coffee we need the coffee so we gonna come back here and say hey serve me not the coins with the coffee it says I don't know this method so let's create that method let's come here and this guy should complain because it doesn't have a method to serve so when the coffee is served we can say this dot actual dispensed coffee is this coffee right that was the coffee we asked it to dispense the barista dispense the coffee we got the coffee let's run this test not in the debug mode so let's get out of that so it says please collect your delicious coffee but was please insert 35 cents sorry we have not changed the message you know see I'm dumb so I make a mistake and I immediately find out that hey I am doing something that I'm not supposed to be doing or I'm missing out stuff right so it's giving me feedback right away yes so yeah so in 10 years of doing this I've yet to come across the system where I didn't find a metaphor so you show me a system where you cannot find a metaphor and let's have a conversation and I'll stand corrected right so in 10 years I have built maybe 30 different systems and I've not come across a system where I couldn't find a metaphor metaphor is an extremely powerful practice and it helps you drive the design right so metaphors are important to make sure all of you are in sync with what I'm thinking in my head right so again I'm yet to find a system but if we find one I'll stand corrected you may we're not trying to model it exactly on the real world but we're trying to say that you know we need this particular entity over here some abstraction to do this bit of work which currently does not belong to the controller right we're calling it barista because that's the metaphor we all understand right if it's something else we will call it something else right I think eclipse is hung so I'm gonna just kill it and bring it back up there we go this is good everything seems to be here hung at this point off okay so let it come back in the meantime I'm gonna jump ahead and I'm gonna show you what I was supposed to do after this right so what we were trying to do here can I get rid of this coffee machine so you guys let me know when that comes up I'm gonna jump ahead a little bit so we started with what I called as the acceptance test right and as we wrote the acceptance test we started flushing out a few concepts we said hey we need American coins right we need coffee type these are abstractions that we started pulling out right we didn't go into implementing any of these we just said this is an abstraction in the system we are trying to build right then we said hey we need a controller right then we said the controller cannot do everything the controller needs a display then we said the controller also needs a cashier the controller also needs a barista right and if you would have completed that loop you would have actually seen the first test go green right so we would have successfully finished one scenario end-to-end working does it do everything absolutely not but did it help us make some progress in understanding what is the behavior and what is the design of this coffee vending machine yes right so now I'm gonna you know as we went through this we had a lot of other scenarios that started coming to our head right if you have a short-term memory like I do have then I would just note it down on a piece of paper and say let me not lose focus for now let me make a note of it and continue till I finish this scenario then I'll come back to saying okay what if I run out of change right or let's say what if I ran out of not coffee but milk right we can also run out of coffee we can run out of the coffee beans but what if I ran out of you know milk what should happen and you might you might not know the answer for it you might need to consult you might need to consult a system expert who understands the system or if there is no system expert you might want to do an AB test you might say let's try these two possible things and see what users might you know like you might go do a survey you might actually build a prototype there are many ways of dealing with that right but let's say you know we ran out of thing we understand that if milk is not available I can still serve a black coffee and I can serve a black coffee with sugar so still two options are all possible but two other options will not be possible how do we know that whose responsibility it is right so on the barista we had a serve method right we can say when the barista serves the coffee it can tell back saying hey I no longer can serve these two coffees and I also will ring this bell so someone will come and fix this thing right so we understand that's two additional behavior that our first scenario did not cover so this guy now returns back what coffees it cannot serve which then the controller needs to do what disable those buttons right the four buttons that we had we might want to disable two of those buttons so what we also realize is we need some kind of an abstraction of buttons over here right and this probably is all encapsulated inside some kind of a front panel which we will then you know used to manage which buttons are turned on and which buttons are turned off and things like that right so each scenario by scenario as you go through this you're actually flushing out the design and you're starting building this thing you're understanding what the behavior should be you're capturing them as executable tests right because these are executable tests I can keep doing them but notice one thing are all these guys implemented at this point these are all just interfaces at this point right yes now I could have spent maybe 30 minutes on this and I could have said alright I see a beginning of a design of a system right now let's get in more people right and give one team to build the display or one person to build the display this is a clear contract of what the behavior of you know the system is at this point in time and the interface that we flushed out tells you what is the contract yes then we move to the cashier we can get one person to do that or a team to do that we might realize that Barista as a fairly complicated thing at this point right so we might actually need to write another acceptance tests at the Barista level to further flush out what the Barista is you know it might have different different dispensers inside it it might have a whole bunch of things inside it right so you might write another acceptance test but when these guys start taking this and writing code what would they do can they write a unit test now because they understand at a high level what is the behavior that is expected right so they can go in now and they can write a unit test over here saying okay for the cashier when this much when this type of coffee is given then this should be the price right I can write a unit test and then go write some code for it right and I can say okay when I need to get change if I give $1 then the change should be so much right so I can unit test drive the cashier does that answer your question yes I can unit test drive the display but this might be fairly complicated which I might not write a unit test I might write an acceptance test right as these individuals start building out the system we want to make sure the acceptance tests are passing all the time right that's the golden state of the system and if this fails then we know something is going wrong somewhere right so right from the beginning you have something which is going to give you very early feedback these tests are also going to evolve by the way you're going to add more tests you're going to change this test if your behavior that you'd originally anticipated has now changed because the requirements have changed you better understood the requirements right so that also happens yes can we unit test controller absolutely actually if you see what we did we actually unit test the controller so what we're calling as the acceptance test is actually a unit test because we have stopped all these guys out at this point right we didn't have any of these guys implemented is all we had is interfaces and we use a technique called self shunting you could use mocking you could use stubbing you could use spies you could use simulators you can use a whole bunch of faking techniques and you could say I have just unit tested my controller right so I would go create I would take I would at this point when I'm about to distribute the work I would actually start with the controller tests which might do some negative path testing at this point which we've not taken care of right that might be more implementation level detail that doesn't need to come here okay correct the acceptance test that you have very of now fake them out you would actually start hooking up one by one and that's what will tell you that these guys are not breaking the system right and this is how we have built fairly large complicated systems to start with it is not a complicated system day one gradually it becomes complicated right but if you have this kind of behavior being defined at various level and automated right from the get go they are complicated but they're under check so that would come into the barista so her question was if there is not sufficient milk or if there's not sufficient coffee right would there be another acceptance test how do you measure that with a sensor so that would drive that we actually need a sensor in this or there are cheaper techniques to do that you could say that you know at this point if it doesn't it doesn't get to you know there are very different techniques so you could use weight for example you could use a small electric point which will say if this is you know touching the point if it goes below that it lights up something it sends a message depends on what behavior how sophisticated you want to build the system right it could send out a message for example to someone to come and fill it could light up the bulb so that's the behavior that you need to define as you go along right now let's pause for a minute and say we did this right is this going to lead us to a good maintainable design with our requirements keep changing all the time right how many people work in companies where your requirements never change yet to find one right there are few people who do build systems like that and soon their companies shut down the shutters right pull down the shutters because that doesn't work in real world right so let's say now our management figured out that hey you know what coffee is not a good business to be in coffee people are getting health conscious and coffee is something that they want to avoid but they are drinking soups so we should be in the business of making these soup machines that can build soups that can make soups right now that happens I've worked in many startups I run my own startup and my developers can tell you how much we pivot how much we change directions so you know the management changes decided to pivot and try something different they say we want to do now soups what would happen to all this effort that we put in throw it out will the display the buttons these change same will the cashier change the data will change but the logic remains the exactly same coffee type will change maybe we need some higher abstraction now we might create a beverage right that's a higher abstraction and then you can do any kind of beverage the barista certainly will change right but that's one part of the system that changed rest whole part of your system remains as is right so this is a fairly significant change now you can go in and write another acceptance test which would define how a soup machine should behave and then make the changes to the barista come up with a dispenser or some other kind of an abstraction which might have different things you management could also decide that we want to do both right will this allow you to do both isn't when you set up your system configuration you could say hey this is a coffee machine so instantiate a coffee barista this is a soup machine so instantiate something else so what I'm trying to get at is requirements change all the time and you know this technique helps us come up with a fairly decoupled design helps us deal with evolving requirements as we go along and caps capture them as automated tests so we can keep validating and distribute work and still be fairly confident that things didn't break randomly okay so that is as in in a nutshell what behavior driven development would look like right this has been applied at very large systems that I have built this has been applied at simple systems we built and this technique seems to work fairly well I do want to show a couple of other things but let's take a few questions before that yeah sure we I wanted to do that yes any other questions has my machine come back from a hanging state not yet the rainbow the beach ball is still there so I am afraid this might not work that's it is an acceptance test is different from an integration test an integration test would only focus on how two components would talk to each other it has no business whatsoever from a functionality or logic point of view and integration only is about whether this point can communicate with this point or not right we do both as as we were discussing earlier so our question is in this style do we do only unit test do we do only acceptance test or do we do both and the answer is we do both because one is a business-facing test which we wrote which is more from a users perspective or from a business perspective but there is also tests that need to validate the implementation of your things right how you're actually implementing something so as it was describing at this point when somebody tries to implement this they would actually write unit test and drive the behavior will drive the implementation of the cashier right so we will do both so just to jump ahead and kind of summarize what your question is in this case these different components that we have can directly talk to each other via method calls right but there will be systems when it will not be a simple method call it could be a distributed system where I have to make a remote call or I need to send a message I need to put something on the message queue and it will do something right so what would we do where would we write at what level would we write the acceptance test we would still write the acceptance test there whether it does a method call whether it's a remote thing that's again implementation detail right your acceptance test should not worry about your implementation detail we will have unit tests and we will have integration tests and we'll have other kinds of tests to make sure whether you can make the remote calls correctly whether you can do these things correctly or not right so that's an implementation detail the acceptance test doesn't care the acceptance this cares how a user would use your system and how a business process would take place or any of those things okay we'll go there okay so the second thing is basically an outside in outside in behavior which would flush out your high level interfaces and things like that okay but you can further go take the same approach and drill it further down like I was explaining the barista is fairly complicated right so let me flush the barista further down again from the same perspective I might actually not even build barista myself I might just buy an offer shelf component which does this right but then I can define what is the off the shelf component needs to do from a behavior point of view hook it in and see if it matches maybe write an adapter in between to do what I want to do exactly okay so that's the second thing what else that's the two things anybody else can you want to add to these other than these two things what is the outcome of this BDD approach emerging the design right which kind of is similar to the second point but I think it's more around the evolving the emerging design things is the evolutionary design right okay that's good so looks like you guys are getting the hang of it what else are the any other advantages or outcome of this okay so we actually did stop out the behavior right it will be actual calls however the unit test for the controller would continue the same thing what we just did would continue as the unit tests obviously more implementation specific tests would be added to the controller unit test but the acceptance test would actually remove one by one all the faking that we did and actually integrate with the real system then we will have to talk about what level of acceptance test are we talking because there are different levels of acceptance test are we talking about business logic acceptance test are we talking about workflow acceptance test are we talking about end-to-end acceptance test so there are three different levels of acceptance test the end-to-end acceptance test should actually integrate cut and cut through the whole system right the business logic acceptance test might only go specific to your module because your module itself is fairly complicated right like the acceptance test over here this only deals with Barista it does not care about the other things at this point. So it depends at what level we are talking this level is generally end to end it integrates with the whole thing there is you know this level might have touch points with other guys and it might just simulate the behavior of other things using any of the mocking techniques any of the faking techniques or any of the simulation techniques there are tools like Lisa for example which can actually record a whole sequence of things when that system is available when the system is not available it will just act as if you are talking to the real system and produce the same output for you right. So that is again another technique you could use so there are whole bunch of different techniques that can be used okay so that seems like a problem to me with the way the acceptance tests are written frankly rather than the that is that is not a common problem let us put it this way that is not a common problem I have seen in large systems there is a system on which I work we had 36,000 acceptance tests that we had written some of them were built by you know ex doctors and nurses and they were building this stuff it was fairly decoupled from your schema because this is business facing this is not technology implementation facing and you need to abstract these things nicely out into some kind of a DSL right which will deal with your low level implementation so changes in your business logic changing in the changes in your workflow should be decoupled fairly from your schema changes or your implementation details right so I think that separation might be is what is missing which is causing these small changes over here in your implementation causing these two change the acceptance test so that's something you might want to you know have a look at correct it's more business facing more user facing rather than more database or you know things like that facing because that's implementation stuff correct it is all real things what I'm saying is you know you're just you know abstracting them encapsulating them in a nice component which will deal with those things right I don't need to so we used for example one one project where we do e-learning we used Selenium to actually drive and build our acceptance tests right so what Selenium would do is we wouldn't say you know in Selenium we would just say you know by the a particular thing we didn't go into details of saying what exactly happens you know we didn't have everywhere saying by means these 10 different click on this click on this click on that that is encapsulated inside one thing which means now if there is a change in the by thing I just need to touch that one point none of my other things would change right but it still would use the same thing hang on let me finish please all right so that abstraction is what I'm talking about is very important okay yes please but shouldn't that be the responsibility of the person who's riding the court right so that person cannot say I'm done unless it's integrated with the database the schema is an up to date everything's hooked up it's working good right and then only they can say okay this particular story or this particular feature or subset of the feature is actually implemented right so that should be the responsibility of the person who says hey I made this change to this court and it is working with the latest greatest schema and the acceptance test is validating that end to end everything is working fine right it should not be a second step should be part of that development cycle okay my systems come back up I want to quickly show a couple of other tools that can be used so you actually appreciate this whole process I am running over time right we're supposed to finish at 5 30 so if you want to leave that's perfectly fine we have actually nothing else up till 6 I'm gonna just eat into that time right so let's look here can everyone see the screen so what I wanted to show you is two other tools I was one of the contributors to a tool called fitness and I'm gonna show you fitness for a second and I'm gonna show you cucumber those are two tools that can be also used for writing acceptance tests that's what I want is I'm gonna show you something real world right rather than a toy code this is this is a domain forwarding server that I built for a company where I worked as everyone familiar with what a domain forwarding server is a domain forwarding server this is an intranet this is an internet company what they do is they provide infrastructure I have two websites nourish Jane.com and nourish Jane.in all right I have two different websites or two different domains would I maintain two different websites for them no I want you know when somebody request for nourish Jane.in I wanted to basically redirect to nourish Jane.com there are a couple of ways of doing that I might want to actually do a permanent redirect and show the URL as nourish Jane.com or I might want to do a URL masking which means it will still show nourish Jane.in but the content is actually served from nourish Jane.com right so there are different techniques of doing that and there's a server called the domain forwarding server which essentially handles this so what you're seeing is acceptance tests or acceptance criteria for domain forwarding server so this says inactive domains should result in bad request so we have this domain which should be forwarded to Google.com but it's not active because they've not paid or they've disabled so when the user request for URL this URL then the header status should be 400 which means bad request right so that's an acceptance tests I can do other things like this so this is active which means they have actually activated it when user request for this domain then the header status should be 301 which is a permanent redirect and now the new location of your browser should be Google.com right I can run this it's a click of a button and I can run this what actually happened when I did this if you notice here oops sorry if you notice here it actually connected to a database it cleaned certain things from the database it inserted a domain in my database I want to do URL masking so which means when I request for this domain the header status should be 200 obviously this is this is not for anyone to just look at it and understand you need to have some basic understanding of the domain right and then we are saying when this thing is requested your fame source should now be Google.com slash blog which means sub domain should become slash blog that's the business logic that we have and that's what we've captured here as this thing right so this is one tool which we use to capture acceptance tests someone would go right this is a wiki so I can go into this edit this thing and I could say you know what header status should be actually 403 this is my behavior I've changed this let me run this and it says expected 403 because that's what we said we expect where actual was 404 so it's actually going hitting the server getting the status back and verifying what's going on let me fix this and so does this make sense what we just did with the coffee vending machine can actually be captured again like this steps over here in a wiki right and there is some glue code that sits behind it which would essentially drive your system which will poke around your system like our you know our acceptance test was actually doing all of this stuff by calling methods on the controller and everything that's what this thing would be doing for you and I want to lastly show another tool which is called cucumber which can do something similar so in cucumber you can write you know pretty much English like statements and it was originally written for Ruby but these days it's available in most languages so here we are saying feature is bad request and the scenario is domain not hosted by our server company server results in a bad request and you're saying given this is a context which means we are not hosting this server when the browser sends a request for this then the header page should not be served the page should not be served and the header status should be 404 right this is fairly just plain text English and we're saying this plain test English is essentially our acceptance criteria acceptance test which would drive our business logic and poke around and validate if things are going fine so again will this just work without anything it obviously needs some code behind it to make this work right so this is what we have written is what we call as the feature file which describes what your scenarios are right and there would be a step definition file which is here so this is all our step definitions each of those lines that you saw in there in this thing is a step definition this one is more complicated was a whole bunch of other stuff each one is a step definition and we are saying that you know the certain things that needs to happen it basically uses regular expression to match what you're giving take important pieces of information out of it and pass it down to your system like here we are doing this business with you know creating a new domain setting certain things on it and storing the domain in the database okay yeah yes the step definitions can be in any language of your choice in fact it was originally built in Ruby but as you can see this is written in Java it can be written in other languages as well if a particular language use and it's not there you can build one because it's fairly easy for fitness as well they have drivers which can work in different languages right so these are all tools that I'm showing you are language agnostic these you know each one has a language specific implementation yes so when we write these then we can actually go and run our tests over here which run cucumber tests and as you can see it ran 101 tests let's step through these these are three top level features that we have bad request permanent redirect and URL masking right well let's look at permanent redirect permanent redirect has these scenarios that we have covered and each of these scenarios have actually gone focused around it has a bunch of steps that is done and it's validated whether things are working or not right so it kind of gives you a nice description and this can also be run all of these tools can be run as part of your continuous integration process which is really the idea there anytime somebody checks in the code it would run all of these and make sure that you didn't accidentally break any of the existing functionality right yeah these are you automated your acceptance tests and this is an automated test that's correct so I was not there in the session but I'll say yes right cool so you see it how it works the mystery solved now all right any other questions that's pretty much it the show is over put your money down on the table if you're happy and leave I'll be around if you have any questions for me all right thank you