DrupalCon Portland 2013

Behat, desarrollo guiado por comportamiento, y Selenium en Drupal

Ryan Weaver  · 


Extracto de la transcripción automática del vídeo realizada por YouTube.

so bear with me thank you yeah I'm really excited to be here I'm come from the symphony side of things hey this is perfect transition into my first slide here there we go so I come from the symphony side of things though we're not gonna talk about

symphony today we're going to talk about B hat and be DD which I am also something it's I'm a part of so that's why this is my first drupalcon and I'm really excited to see over here and really says be here in fact there we go now I can

actually see everybody way back there so I'm in the symphony world i do symphonies documentation primarily i also this is my one slide to sort of pimp myself that that's the company I work for campy labs us we do mostly consulting and training around

the symphony sphere so like I said I'm all set everything symphony this has been sort of crazy so far this week to be a part of what basically is about eight times the size of our normal conferences so it's been awesome I'm also a writer for camp

University com which is basically screencast in other ways to learn things online with good practices and actually not boring and I'll mention that again later because I'm gonna give you guys all a coupon code for a free screencast that's going

to cover what we're going to cover today in more detail so if you like what you see today with be hat and be DD which I think you will you can keep running with it for free after this so I'll come back to that later ah most importantly i'm the

husband of the much more talented atlanta pelham and she's fairly well known in the sympathy world because I put her in each of my presentations like this how many people know Liana that's yeah the the two people in the room I know basically so so

yeah when I did that in symphony thing it was like three quarters of the room raised their hand so if you could all so my favorite things to do before the cat got out of the back of the symphony committee about her if you could all if you have your phone's

just tweet at her right now so that's her name just say hi she's here you could say because I don't know just you can you can heckle me towards her and she can provide me with that heckling feedback afterwards so that's probably less distracting

and heckling me during it so say hi to her and she's here also and she's awesome and she's the voice behind camp University come on I do not want to have to advance myself that's what I'll do there we go okay alright so today we're

talking about be HAP behavior driven development so let's back up real quick a little bit of background where things break down in projects and I think we will all at least more or less review with this is the organization of the projects not necessarily

the development it's the whole mess of who's doing what and how are we even organizing and planning the features that we're building so the typical project and probably this is somewhat familiar to people how many people how many people have seen

this series yeah okay good but I'm probably like half people yeah so there's like a million of these things but this is basically what I'm talking about so how the customer explained it how the project leader understood it how the programmer wrote

it which I actually really like because that just makes no sense at all I'm a programmer by the way so if I'm ripping on programmers I'm ripping on myself I'm not an outsider what the customer really needed and my personal favorites which is

what we gave to the beta testers it's funny because it hits close to home right okay so yeah so it's sort of funny because this is all like computer science right and this is sort of what actually happens in the real world and it's funny because

it has too close to home so where it breaks down first and foremost is different roles different languages people of different technical levels than we are all very important in the overall process so we have to work together but we use different languages

and part of the reason to use different languages I was because we're at different technical levels this one is especially I like for programmers is that our code may not align with our business value the only reason we really write code I mean this is

not necessarily totally true because as programmers we'd like to write code but the only reason we're supposed to write code is for business value one way or another even if that's your pet project there's sort of business value in that pet

project so does your code actually align with what your business needs or does your code did you kind of go off in a direction for four straight days because something was really cool or interesting and really wasn't that important so being able to align

what we're actually coding with the business values so that it's basically we bring as much value but the company with as little effort as possible and this is basically what I'm talking about so as if you like to program then this is probably

at some way in the back of your mind you're like that's really cool i should run with that and keep programming in and I know I'm supposed to be doing this other thing on the first thing is sort of over planning under planning planning that whole

process how much do we plan are we planning at all are we over planning are we having meetings like to our meetings every day six hours of meetings every day anybody are we not planning at all so kind of getting the planning process so that it we have to plan

right but actually getting it so that we have almost a plan for our plan how do we plan efficiently okay so let's get down to the the bdd stuff behavior driven development so here's sort of the evolution of test-driven development here way back when

somebody said hey we should start testing our code there's unit tests back there said okay we have a function when I call this function I need to assert that basically when I put three and five in it it comes back as eight because that function is called

ad okay and then later said somebody said we should write our test first so if we're going to write to the by the way use a calculator thing because that's sort of the age-old unit testing example today we should write our tests first and then implement

our code in the advantage there being that this is something that's really good for behavior driven development as well is that as programmers we need to know when to stop we need to know when the requirements have actually been fulfilled so with test-driven

development I write the test first and I stopped working go home as soon as all my tests are green and I don't need to program any further than that because all my tests are passing so I basically done my job then finally a behavior driven development

/ that's what we're going to talk about and it's very very interesting by far the most interesting thing on here at least from my perspective so the the the the grandpa of this of course in technology if you're a grandpa of something it happened

only ten years ago the grandpa this is dan north and he said this is a good quote said behavior is a more useful word than test ideas we need test for application but instead of having them be something that's buried in the developers fearsome where it's

very technical we want to elevate those so the tests themselves are more about the behavior what does the user do did they go to this page they click this link when they click this link what did they see that's the kind of language that developers understand

that's what they're building all the way up to the least technical people they understand that that's what they're doing as well I'll mention this really quickly I'm not going to go over this but if you are curious about this there's

two types of BDD there's story BTW their spec BDD roughly what that's talking about is unit test versus functional test if that's not making any sense to you don't worry about it if you're like ooh I mean I know what that means and that's

really interesting then go ahead and check out if you're interested in the spec we're gonna talk about the story BDD so if you're interested about the spec BDD then you can check out this library which you're not going to talk about it's

a little bit low level it's a little bit more of a developer tool only but it's also very nice so we're going to talk about what's called scenario oriented BDD and by the way we're gonna do actually that's how many people would in the

room would consider themselves developers okay that's good that's kind of I thought that was most of the room and for those of you that didn't raise your hands it's okay we're also going to be going through stuff that's kind of useful

across the whole thing because the whole idea of what we're doing is supposed to be kind of something that can be done on an organization-wide basis though we're actually going to be going into real code but developers hang on with me for just like

two minutes because we have to get a little bit of philosophy and they'll actually going to the actual practices here so with behavior driven development the goal is to create that single vocabulary so that when we're describing a feature we're

all kind of using the same language to do it and this comes from all the way from somebody having like this big idea that they don't know about all the way down into implementing and testing it at every stage we're trying to get back down to like what's

the actual feature supposed to do in this specific language so this is the four-part process that we're going to file and this is the theoretical part this we're going to go through these one by one in a second but basically here's the situation

somebody comes with you it's just big idea it's like the owner of the company like bust into your office or maybe your home on the weekend hopefully not listen to your office and has this big idea and now we need to get that big idea kind of down into

something that's saying so first we're gonna do is it is probably is coming in with what we consider maybe five different features because he's like admin area this and front end this and mobile that okay so the first thing I do is we're going

to define the business value first one do is focus on the business value of whatever the idea is if it doesn't have business value then it's not actually something we should work on second thing is we're going to prioritize those now that we've

sort of defined five different features and their business value or prioritize those this one is the most important this one is the least important step three and this is where things get interesting we're going to describe those with readable scenarios

and we'll see scenarios later but they're actually when we start talking about what the actual user story is meaning they go to this page they click on this they do this that would be a scenario describing your feature and then finally and of course

this is the behavior driven development part once we've done all that we're actually going to implement it so the idea is we can describe in this language exactly how future supposed to work and that's actually the starting point for the development

process regardless of whether the developers the ones that wrote that or for project managers ones I've written that we actually have this specification and the important thing here is the specification is from the users perspective because no one on the

business side cares whether or not we had to create a new database table for this what they care about is the users behavior you're able to go to this page click on this and see this result so that needs to be the starting point for us as developers to

actually make sure that we're accomplishing the end behavior the end goal that they want so this is where something called gherkin comes in how many people have heard of gherkin okay okay it's like a 25 percent or so unfortunately it's very easy

gherkin is a language and it's the language that is used to describe features again we have all these ideas somehow we have to sit down ideally it doesn't have to be this way but what if we are all describing these features with a structured language

because obviously like anything else we're developers so we know that if we're all speaking the same language then we're going to communicate more efficiently so a project consists of many features that need to be planned planned written and shared

somehow already it might just be right now an email or something that's jotted on a piece of paper and then hand it to you so gherkin is the structured language to do that and it looks like this so again the idea is that we have five features coming in

and we've decided to put separate those five features and we're going to do this so this would actually go into a file and we would describe the feature using this format now there's three sort of I guess there's four variables they're

the first ones just feature and that's just a title so we do something like feature and just kind of some title that you would know this is a feature for the admin area then the three other parts are very very important the first part in order to this

defines the business value and it's print for developers this is the hardest one to get right because we're not used to necessarily thinking about the business value and I'll go over some good ones and some bad ones later but we typically think

of something like in order to let's sit here like in order to access the admin area that's your business value i was like accessing the admin area is not business value you're not making any money because your atom is able to go into the add the

admin area you're making money because something more like in order to be managed the products that are on the front of our site that's kind of the business value so a is the business value and i'll give examples of these specifics b is the role

[ ... ]

Nota: se han omitido las otras 7.212 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.